Address nominal versus structural typing in rejected alternatives

[ceridwen]

I know this was already mentioned in #10 and #11 and that a structural typing solution was explicitly deferred, but I feel like it would be useful to at least bring it up in the rejected alternatives section of PEP 484 to answer two questions: why was nominal typing (as in mypy) chosen over structural typing (as in Reticulated Python) for 3.5? Is Python's type system changing to emphasize nominal typing over structural typing? (For anyone unfamiliar with the difference between nominal and structural typing, Laurie Tratt's article on dynamic typing gives a brief overview in Sections 2.3 and 5.7. As Tratt mentions, in dynamic languages structural typing is often called duck typing.)

I'm asking because I'm not sure what to think about duck typing in Python any more. On one hand, people talking about Python and particularly its type system often mention duck typing, often in the context of LBYL and EAFP. There are also some parts of the standard library that are duck-typed like contextlib.closing and many classes and functions that operate on file-like objects. On the other hand, Python has always had nominal typing features like isinstance and issubclass, duck typing only receives a few mentions in the documentation (in the glossary and a few places in the What's New documents) and only one in the Python history blog, and there are standard library modules that are not duck-typed at all like pprint. ABCs have some characteristics of nominal typing, because to be considered a member of an ABC for isinstance and issubclass a type has to either inherit from an ABC explicitly or has to be registered with the ABC, but also some characteristics of structural typing, since they force subclasses to have specific methods. New features like functools.singledispatch and now type hinting are based on nominal typing.

The paper on Reticulated Python mentions nominal versus structural typing but doesn't do much to make a case for structural typing other than to mention that, "Structural object types are an appropriate match for Python's duck typing." mypy itself addresses why it uses nominal instead of structural typing briefly in its FAQ. I don't know if there's anything in either worth including in the PEP.

[gvanrossum]

This is probably better for a discussion on python-ideas or here in the tracker than for a precise response in the PEP. Duck typing is very well known but I believe its actual use is pretty narrow -- lots of file-like objects, lots of things implementing the Sequence or Mapping ABCs, the occasional proxy hack, and of course test mocks. But if you have an app that defines a bunch of classes e.g. User, Blog, Post, etc., you are quite unlikely to care about structural subtyping. Such code is often seen to use things like assert isinstance(u, User) and this is an indication that the annotation (u: User) makes sense.

[gvanrossum]

Duplicate of #11.