msg68815 - (view) |
Author: Paddy McCarthy (paddy3118) |
Date: 2008-06-27 05:10 |
The official glossary entry here: http://docs.python.org/tut/node18.html#l2h-46 says: " duck-typing Pythonic programming style that determines an object's type by inspection of its method or attribute signature rather than by explicit relationship to some type object ("If it looks like a duck and quacks like a duck, it must be a duck.") By emphasizing interfaces rather than specific types, well-designed code improves its flexibility by allowing polymorphic substitution. Duck-typing avoids tests using type() or isinstance(). Instead, it typically employs hasattr() tests or EAFP programming. " I think it is should be changed to delete the use of hasattr and just rely on EAFP as in the second example here: http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Exceptions The text would then read: " duck-typing Pythonic programming style that determines an object's type by inspection of its method or attribute signature rather than by explicit relationship to some type object ("If it looks like a duck and quacks like a duck, it must be a duck.") By emphasizing interfaces rather than specific types, well-designed code improves its flexibility by allowing polymorphic substitution. Duck-typing avoids tests using type(), hasattr() or isinstance(). Instead, it typically employs an EAFP style of programming. " The reason is that a hasattr test only tests for an attribute name. If it is present and say the method signature is wrong, then its the excecution of the code using the attribute that will find that out so it is redundant. Best to use EAFP for Duck typing as we trust you know what it is you are doing. - Paddy. |
|
|
msg68829 - (view) |
Author: Benjamin Peterson (benjamin.peterson) *  |
Date: 2008-06-27 14:00 |
Georg, you may also want to amend this entry for ABCs. |
|
|
msg69070 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2008-07-01 20:35 |
Paddy: IMO hasattr() is the "if it quacks like a duck" part of duck-typing. It e.g. allows testing "hasattr(x, 'write')" to see if it's a writable file-like object, and doing something else otherwise. Benjamin: ABCs are not duck-typing since they involve isinstance() anyway. |
|
|
msg69085 - (view) |
Author: Paddy McCarthy (paddy3118) |
Date: 2008-07-02 05:27 |
Hi Georg, A bit of relevant background about me: I've been interested in Duck Typing _specifically_ for a couple of years when I started watching edits to it on Wikipedia. I researched the history of the use of the term and changed the attribution of first use to Alex Martelli after digging in Google, and still trawl reading code and articles on the subject. But I DONT think this makes me an expert - Duck typing is a 'mould-able' term and the things we write about it help to define it. On your comment about hasattr: I think more and more that Duck-Typing is what allows us, (as in Python), to substitute one class for another in a method previously designed with only the other in mind - you know, as in the canonical example of file-like objects such as StringIO substituting in methods defined originally for files. In this case hasattr checks don't add anything, and EAFP is all important. I tried to get wider context on this by posting it originally to comp.lang.python but no one was interested. I don't normally frequent the developers forumbut maybe we should open the issue to that audience? - Paddy. |
|
|
msg69086 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-07-02 06:51 |
While we are at it, should we keep this one as is? « Python3000 A mythical python release, not required to be backward compatible, with telepathic interface. » Not so mythical after all... missing the telepathic interface though. |
|
|
msg109680 - (view) |
Author: Terry J. Reedy (terry.reedy) *  |
Date: 2010-07-09 04:41 |
I actually would challenge the first sentence "A pythonic programming style which determines an object’s type by inspection of its method or attribute signature ". To me, and at least some usage on python-list, duck-typing means determining the interface (not type) by calling methods and catching exceptions if not present. This is the EAFP rather than inspection/LBYL style of duck typing. In 3.1: Python 3000 Nickname for the Python 3.x release line (coined long ago when the release of version 3 was something in the distant future.) This is also abbreviated “Py3k”. I suspect this was backported at the same time. |
|
|
msg109698 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2010-07-09 09:25 |
> I actually would challenge the first sentence "A pythonic programming > style which determines an object’s type by inspection of its method or > attribute signature ". To me, and at least some usage on python-list, > duck-typing means determining the interface (not type) by calling > methods and catching exceptions if not present. This is the EAFP > rather than inspection/LBYL style of duck typing. Indeed. I would also remove "pythonic", because it will only confuse the beginner. |
|
|
msg109846 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2010-07-10 10:40 |
Thanks, fixed the first sentence in r82760. |
|
|
msg109938 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-07-10 21:24 |
Benjamin: Georg, you may also want to amend this entry for ABCs. Georg: ABCs are not duck-typing since they involve isinstance() anyway. Since ABCs provide virtual subclassing, using hasattr without requiring subclassing or registering, isn’t Benjamin right after all? |
|
|
msg109939 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-07-10 21:26 |
Re-reading the glossary for both entries, they already link to each other, and the subtleties of ABCs can be learned later in their documentation. The glossary is good, sorry for the noise. |
|
|
msg109940 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-07-10 22:07 |
To make one useful comment today: I noticed one missing :term: construct to link ABCs from duck typing. Attaching patch. |
|
|
msg109996 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-07-11 11:38 |
Applied in r82790 by Georg, thanks! |
|
|