Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggest change to glossary explanation: "Duck Typing" #47464

Closed
paddy3118 mannequin opened this issue Jun 27, 2008 · 12 comments
Closed

Suggest change to glossary explanation: "Duck Typing" #47464

paddy3118 mannequin opened this issue Jun 27, 2008 · 12 comments
Assignees
Labels
docs Documentation in the Doc dir type-feature A feature request or enhancement

Comments

@paddy3118
Copy link
Mannequin

paddy3118 mannequin commented Jun 27, 2008

BPO 3214
Nosy @birkenfeld, @terryjreedy, @pitrou, @benjaminp, @merwok
Files
  • add-ref.diff
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/birkenfeld'
    closed_at = <Date 2010-07-10.10:40:08.823>
    created_at = <Date 2008-06-27.05:10:59.099>
    labels = ['type-feature', 'docs']
    title = 'Suggest change to glossary explanation:  "Duck Typing"'
    updated_at = <Date 2010-07-11.11:38:54.336>
    user = 'https://bugs.python.org/paddy3118'

    bugs.python.org fields:

    activity = <Date 2010-07-11.11:38:54.336>
    actor = 'eric.araujo'
    assignee = 'georg.brandl'
    closed = True
    closed_date = <Date 2010-07-10.10:40:08.823>
    closer = 'georg.brandl'
    components = ['Documentation']
    creation = <Date 2008-06-27.05:10:59.099>
    creator = 'paddy3118'
    dependencies = []
    files = ['17937']
    hgrepos = []
    issue_num = 3214
    keywords = ['patch']
    message_count = 12.0
    messages = ['68815', '68829', '69070', '69085', '69086', '109680', '109698', '109846', '109938', '109939', '109940', '109996']
    nosy_count = 6.0
    nosy_names = ['georg.brandl', 'terry.reedy', 'pitrou', 'paddy3118', 'benjamin.peterson', 'eric.araujo']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue3214'
    versions = ['Python 2.6', 'Python 3.1', 'Python 2.7', 'Python 3.2']

    @paddy3118
    Copy link
    Mannequin Author

    paddy3118 mannequin commented Jun 27, 2008

    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.

    @paddy3118 paddy3118 mannequin assigned birkenfeld Jun 27, 2008
    @paddy3118 paddy3118 mannequin added docs Documentation in the Doc dir type-feature A feature request or enhancement labels Jun 27, 2008
    @benjaminp
    Copy link
    Contributor

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

    @birkenfeld
    Copy link
    Member

    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.

    @paddy3118
    Copy link
    Mannequin Author

    paddy3118 mannequin commented Jul 2, 2008

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Jul 2, 2008

    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.

    @terryjreedy
    Copy link
    Member

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Jul 9, 2010

    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.

    @birkenfeld
    Copy link
    Member

    Thanks, fixed the first sentence in r82760.

    @merwok
    Copy link
    Member

    merwok commented Jul 10, 2010

    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?

    @merwok
    Copy link
    Member

    merwok commented Jul 10, 2010

    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.

    @merwok
    Copy link
    Member

    merwok commented Jul 10, 2010

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

    @merwok
    Copy link
    Member

    merwok commented Jul 11, 2010

    Applied in r82790 by Georg, thanks!

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    docs Documentation in the Doc dir type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants