<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 10, 2015 at 3:01 AM, Luciano Ramalho <span dir="ltr"><<a href="mailto:luciano@ramalho.org" target="_blank">luciano@ramalho.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jukka, thank you very much for working on such a hard topic and being<br>
patient enough to respond to issues that I am sure were exhaustively<br>
discussed before (but I was not following the discussions then since I<br>
was in the final sprint for my book, Fluent Python, at the time).<br>
<br>
I have two questions which were probably already asked before, so feel<br>
free to point me to relevant past messages:<br>
<br>
1) Why is a whole new hierarchy of types being created in the typing<br>
module, instead of continuing the hierarchy in the collections module<br>
while enhancing the ABCs already there? For example, why weren't the<br>
List and Dict type created under the existing MutableSequence and<br>
MutableMapping types in collections.abc?<br></blockquote><div><br></div><div>There are two main reasons. First, we wanted typing to be backward compatible down to Python 3.2, and so all the new features had to work without any changes to other standard library modules. Second, the module is provisional and it would be awkward to have non-provisional standard library modules depend on or closely interact with a provisional module.</div><div><br></div><div>Also, List and Dict are actually type aliases for regular classes (list and dict, respectively) and so they actually represent subclasses of MutableSequence and MutableMapping as defined in collections.abc. They aren't proper classes so they don't directly play a role at runtime outside annotations.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) Similarly, I note that PEP-484 shuns existing ABCs like those in<br>
the numbers module, and the ByteString ABC. The reasons given are<br>
pragmatic, so that users don't need to import the numbers module, and<br>
would not "have to write typing.ByteString everywhere." as the PEP<br>
says... I don not understand these arguments because:<br>
<br>
a) as you just wrote in another message, the users will be primarily<br>
the authors of libraries and frameworks, who will always be forced to<br>
import typing anyhow, so it does not seem such a burden to have them<br>
import other modules get the benefits of type hinting;<br></blockquote><div><br></div><div>I meant that protocols will likely be often *defined* in libraries or frameworks (or their stubs). Almost any code can *use* protocols in annotations, but user code might be less likely to define additional protocols. That's just a guess and I could be easily proven wrong, though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
b) alternatively, there could be aliases of the relevant ABCs in the<br>
typing module for convenience<br></blockquote><div><br></div><div>There are other reasons for not using ABCs for things like numbers. For example, a lot of standard library functions expect concrete numeric types and won't accept arbitrary subclasses of the ABCs. For example, you couldn't pass a value with the numbers.Integral type to math.sin, because it expects an int or a float. Using ABCs instead of int, float or str wouldn't really work well (or at all) for type checking.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So the second question is: what's wrong with points (a) and (b), and<br>
why did PEP-484 keep such a distance form existing ABCs in general?<br></blockquote><div><br></div><div>See above. There are more reasons but those that I mentioned are some of the more important ones. If you are still unconvinced, ask for more details and maybe I'll dig through the archives. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I understand pragmatic choices, but as a teacher and writer I know<br>
such choices are often obstacles to learning because they seem<br>
arbitrary to anyone who is not privy to the reasons behind them. So<br>
I'd like to better understand the reasoning, and I think PEP-484 is<br>
not very persuasive when it comes to the issues I mentioned.<br></blockquote><div><br></div><div>Yeah, PEP 484 doesn't go through the rationale and subtleties in much detail. Maybe there should be a separate rationale PEP and we could just link to it when we get asked some of these (quite reasonable, mind you!) questions again. ;-)</div><div><br></div><div>Jukka</div></div></div></div>