As demonstrated, protocols don't get us there because duck typing isn't a matter of having an object exhibit all of the attributes of a duck, but rather some subset of attributes to be used by the consumer. I want this duck to quack; someone else will want it to waddle. I don't see how type hints could reasonably support "file like object" in the duck type sense (unless the consumer were to specify the exact attributes of the duck it's interested in, which I fear would become a tedious type writing style).
I too have sensed static typing driving the typing development agenda in Python recently, causing other typing methods to take a back seat, so to speak. I add my voice to those requesting Python handle other typing methods. Barring an innovation to allow a "subset" of a type to be declared in a type hint, I would conclude that static typing and duck typing are diametrically opposed. If we agree that both are valuable, developers could build consensus on that point, and work to ensure that one does not move forward at the expense of the other. Paul On Wed, 2021-04-21 at 12:36 -0700, Christopher Barker wrote: > Thanks Mark for posting this. I know some of us are uneasy about the > pace of the typing train .... > > On Tue, Apr 20, 2021 at 11:20 AM Nathaniel Smith <n...@pobox.com> > wrote: > > > If you guarded your code with `isinstance(foo, Sequence)` then I > > could > > > not use it with my `Foo` even if my `Foo` quacked like a > > sequence. I was > > > forced to use nominal typing; inheriting from Sequence, or > > explicitly > > > registering as a Sequence. > > > > You say this like it's a bad thing, but how is this avoidable, even > > in > > principle? Structural typing lets you check whether Foo is duck- > > shaped > > -- has appropriate attribute names, etc. But quacking like a duck > > is > > harder: you also have to implement the Sequence behavioral > > contract, > > and realistically the only way to know that is if the author of Foo > > tells you. > > > > > But that's not what duck typing is (at least to me :-) ) For a given > function, I need the passed in object to quack (and yes, I need that > quack to sound like a duck) -- but I usually don't care whether that > object waddles like a duck. > > So yes, isinstance(obj, Sequence) is really the only way to know that > obj is a Sequence in every important way -- but if you only need it > to do one or two things like a Sequence, then you don't care. > > And this is not uncommon -- I suspect it's very rare for a single > function to use most of the methods of a given ABC (or protocol, or > whatever). > > And a lot of the standard library works exactly this way. Two > examples (chosen arbitrarily, I just happen to have thought about how > they work): > > json.load() simply calls ``fp.read()``, and passes the result on down > to json.loads(). That's it -- no checking of anything. > > If fp does not have a read() method, you get an AttributeError. If fp > has a read() method, but it returns something other than a string, > then you get some other Exception. And if it returns a string, but > that string isn't valid JSON, you get yet another kind of error. > > In short, json.load(fp, ...) requires fp to have a read() method that > returns a valid JSON string. But it doesn't check, nor does it need > to, if it's getting an actual io.TextIOBase object. Is that the right > one? I'm not totally sure, which I kind of think makes my point -- > I've been using "file-like" objects for years (decades) without > worrying about it. > > Example 2: > > The str.translate method takes: > > "a mapping of Unicode ordinals to Unicode ordinals, strings, or None" > > Ok, then you need to pass in a Mapping, yes? Well, no you don't. The > docs go on to say: > > The table must implement lookup/indexing via __getitem__, for > instance a > dictionary or list. > > Ah -- so we don't need a Mapping -- we need anything indexable by an > integer that contains "ordinals, strings, or None". What the heck ABC > could we use for that? > > The ABCs do have an already complex hierarchy of containers, but > there is no "Indexable", (quacks) and certainly no "indexable and > returns these particular things. (quacks a certain way). (maybe > there's something in the typing module that would work for static > typing -- I have no idea). > > I'm pretty sure this particular API was designed to accommodate the > old py2 str.translate, which took a length-256 sequence, while also > accommodating full Unicode, which would have required a 2^32 length > sequence to do the same thing :-) > > But again -- this is duck typing, built into the stdlib, and it works > just fine. > > Granted, until PEP 563 (kind of) , there has been nothing that > weakens or disallows such duck typing -- those of us that want to > write fully duck-typed code can continue to do so. > > But there is the "culture" of Python -- and it has been very much > shifting toward more typing -- A recent publication (sorry can't find > it now -- my google fu is failing me) examined code on PyPi and found > a lot of type hints -- many of which were apparently not being used > with a static type checker. So why were they there? > > And I've seen a lot more isinstance(Some_ABC) code lately as well. > > From looking at the work of my beginning students, I can tell that > they are seeing examples out there that use more typing, to the point > that they think it's a best practice (or maybe even required?). Maybe > it is -- but if the community is moving that way, we should be honest > about it. > > > I'm not even sure that this *is* nominal typing. You could just as > > well argue that "the operation `isinstance(..., Sequence)` returns > > `True`" is just another of the behavioral constraints that are > > required to quack like a sequence. > > > > > I'm not sure of the definition of "nominal" typing -- but it > absolutely is NOT duck typing (As Luciano pointed out, Alex Martelli > coined the term Goose Typing for this). > > The big distinction is whether we want to know if the object is a > duck, or if we only need it to do one or two things like a duck. > > -CHB > > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ZXI3RTBVW44WGX44D4OFSH6GXL3SYPVO/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PDW6UUK2QFS3J6B6SIQGUE2E7J7IELIS/ Code of Conduct: http://python.org/psf/codeofconduct/
