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.

Georg, you may also want to amend this entry for ABCs.

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.

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.

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.

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.

> 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.

Thanks, fixed the first sentence in r82760.

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?

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.

To make one useful comment today: I noticed one missing :term: construct to link ABCs from duck typing. Attaching patch.

Applied in r82790 by Georg, thanks!