[Python-ideas] Structural type checking for PEP 484
Andrew Barnert
abarnert at yahoo.com
Thu Sep 10 00:08:04 CEST 2015
On Sep 9, 2015, at 13:17, Guido van Rossum <guido at python.org> wrote:
>
> Jukka wrote up a proposal for structural subtyping. It's pretty good. Please discuss.
>
> https://github.com/ambv/typehinting/issues/11#issuecomment-138133867
Are we going to continue to have (both implicit and explicit) ABCs in collections.abc, numbers, etc., and also have protocols that are also ABCs and are largely parallel to them (and implicit at static checking time whether they're implicit or explicit at runtime) In typing? If so, I think we've reached the point where the two parallel hierarchies are a problem.
Also, why are both the terminology and implementation so different from what we already have for ABCs? Why not just have a decorator or metaclass that can be added to ABCs that makes them implicit (rather than writing a manual __subclasshook__ for each one), which also makes them implicit at static type checking time, which means there's no need for a whole separate but similar notion?
I'm not sure why it's important to also have some times that are implicit at static type checking time but not at runtime, but if there is a good reason, that just means two different decorators/metaclasses/whatever (or a flag passed to the decorator, etc.). Compare:
Hashable is an implicit ABC, Sequence is an explicit ABC, Reversible is an implicit-static/explicit-runtime ABC.
Hashable is an implicit ABC and also a Protocol that's an explicit ABC, Sequence is an explicit ABC and not a Protocol, Reversible is a Protocol that's an explicit ABC.
The first one is clearly simpler; is there some compelling reason that makes the second one better anyway?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150909/6e5a7e51/attachment.html>
More information about the Python-ideas
mailing list