Re: [Python-Dev] PEP 544: Protocols
I'm a big fan of this. I really want structural subtyping for http://github.com/google/pytype. On Mon, Mar 20, 2017 at 5:00 AM, Ivan Levkivskyi wrote: > Explicitly declaring implementation > --- > > To explicitly declare that a certain class implements the given protocols, > Why is this necessary? The whole point of ducktyping is that you *don't* have to declare what you implement. I get that it looks convenient to have your protocol A also supply some of the methods you'd expect classes of type A to have. But completing an implementation in that way should be done explicitly (via including a utility class or using a decorator like functools.total_ordering), not as side-effect of an (unnecessary) protocol declaration. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 544: Protocols
On Mon, Mar 20, 2017 at 2:42 PM, Ivan Levkivskyi wrote: > 1. Backward compatibility: People are already using ABCs, including > generic ABCs from typing module. > If we prohibit explicit subclassing of these ABCs, then quite a lot of > code will break. > Fair enough. Backwards compatibility is a valid point, and both abc.py and typing.py have classes that lend itself to becoming protocols. The one thing that isn't clear to me is how type checkers will distinguish between 1.) Protocol methods in A that need to implemented in B so that B is considered a structural subclass of A. 2.) Extra methods you get for free when you explicitly inherit from A. To provide a more concrete example: Since Mapping implements __eq__, do I also have to implement __eq__ if I want my class to be (structurally) compatible with Mapping? > If you think it makes sense to add a note that implicit subtyping is > preferred (especially for user defined protocols), > then this certainly could be done. > Yes, I believe it would be good to mention that. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 544: Protocols
On Tue, Mar 21, 2017 at 11:05 AM, Ivan Levkivskyi wrote: > There are two places where PEP draft says: > > "Note that there is no conceptual difference between explicit and implicit > subtypes" > > and > > "The general philosophy is that protocols are mostly like regular ABCs, > but a static type checker will handle them specially." > > Do you want to propose alternative wording for these, or would you rather > like an additional statement? > Let's do an additional statement. Something like "Static analysis tools are expected to automatically detect that a class implements a given protocol. So while it's possible to subclass a protocol explicitly, it's not necessary to do so for the sake of type-checking." ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
