[Python-ideas] Structural type checking for PEP 484

[Luciano Ramalho]

Jukka, thank you very much for working on such a hard topic and being
patient enough to respond to issues that I am sure were exhaustively
discussed before (but I was not following the discussions then since I
was in the final sprint for my book, Fluent Python, at the time).

I have two questions which were probably already asked before, so feel
free to point me to relevant past messages:

1) Why is a whole new hierarchy of types being created in the typing
module, instead of continuing the hierarchy in the collections module
while enhancing the ABCs already there? For example, why weren't the
List and Dict type created under the existing MutableSequence and
MutableMapping types in collections.abc?

2) Similarly, I note that PEP-484 shuns existing ABCs like those in
the numbers module, and the ByteString ABC. The reasons given are
pragmatic, so that users don't need to import the numbers module, and
would not "have to write typing.ByteString everywhere." as the PEP
says... I don not understand these arguments because:

a) as you just wrote in another message, the users will be primarily
the authors of libraries and frameworks, who will always be forced to
import typing anyhow, so it does not seem such a burden to have them
import other modules get the benefits of type hinting;
b) alternatively, there could be aliases of the relevant ABCs in the
typing module for convenience

So the second question is: what's wrong with points (a) and (b), and
why did PEP-484 keep such a distance form existing ABCs in general?

I understand pragmatic choices, but as a teacher and writer I know
such choices are often obstacles to learning because they seem
arbitrary to anyone who is not privy to the reasons behind them. So
I'd like to better understand the reasoning, and I think PEP-484 is
not very persuasive when it comes to the issues I mentioned.

Thanks!

Best,

Luciano

-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
|     http://shop.oreilly.com/product/0636920032519.do
|  Professor em: http://python.pro.br
|  Twitter: @ramalhoorg