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 21 March 2017 at 17:09, Matthias Kramm wrote: > > 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? > An implicit subtype should implement all methods, so that yes, in this case __eq__ should be implemented for Mapping. There was an idea to make some methods "non-protocol" (i.e. not necessary to implement), but it was rejected, since this complicates things. Briefly, consider this function: def fun(m: Mapping): m.keys() The question is should this be an error? I think most people would expect this to be valid. The same applies to most other methods in Mapping, people expect that they are provided my Mapping. Therefore, to be on the safe side, we need to require these methods to be implemented. If you look at definitions in collections.abc, there are very few methods that could be considered "non-protocol". Therefore, it was decided to not introduce "non-protocol" methods. There is only one downside for this: it will require some boilerplate for implicit subtypes of Mapping etc. But, this applies to few "built-in" protocols (like Mapping and Sequence) and people already subclass them. Also, such style will be discouraged for user defined protocols. It will be recommended to create compact protocols and combine them. (This was discussed, but it looks like we forgot to add an explicit statement about this.) I will add a section on non-protocol methods to rejected/postponed ideas. -- Ivan ___ 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
Technically, `__eq__` is implemented by `object` so a `Mapping` implementation that didn't implement it would still be considered valid. But probably not very useful (since the default implementation in this case is implemented by comparing object identity). On Tue, Mar 21, 2017 at 9:36 AM, Ivan Levkivskyi wrote: > On 21 March 2017 at 17:09, Matthias Kramm wrote: > >> >> 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? >> > > An implicit subtype should implement all methods, so that yes, in this > case __eq__ should be implemented for Mapping. > > There was an idea to make some methods "non-protocol" (i.e. not necessary > to implement), but it was rejected, > since this complicates things. Briefly, consider this function: > > def fun(m: Mapping): > m.keys() > > The question is should this be an error? I think most people would expect > this to be valid. > The same applies to most other methods in Mapping, people expect that > they are provided my Mapping. Therefore, to be on the safe side, we need > to require these methods to be implemented. If you look at definitions in > collections.abc, > there are very few methods that could be considered "non-protocol". > Therefore, it was decided > to not introduce "non-protocol" methods. > > There is only one downside for this: it will require some boilerplate for > implicit subtypes of Mapping etc. > But, this applies to few "built-in" protocols (like Mapping and Sequence) > and people already subclass them. > Also, such style will be discouraged for user defined protocols. It will > be recommended to create compact > protocols and combine them. (This was discussed, but it looks like we > forgot to add an explicit statement about this.) > > I will add a section on non-protocol methods to rejected/postponed ideas. > > -- > Ivan > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ 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, 21 Mar 2017 at 09:17 Matthias Kramm via Python-Dev < [email protected]> wrote: > 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. > Another key point is that if you block subclassing then this stops being useful to anyone not using a type checker. While the idea of protocols is to support structural typing, there is nothing wrong with having nominal typing through ABCs help enforce the structural typing of a subclass at the same time. You could argue that if you want that you define the base ABC first and then have a class that literally does nothing but inherit from that base ABC and Protocol, but that's unnecessary duplication in an API to have the structural type and nominal type separate when we have a mechanism that can support both. > > 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. > I don't think it needs to be explicitly discouraged if you want to make sure you implement the abstract methods (ABCs are useful for a reason). I do think it's fine, though, to make it very clear that whether you subclass or not makes absolutely no difference to tools validating the type soundness of the code. ___ 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 21 March 2017 at 18:03, Brett Cannon wrote: > I do think it's fine, though, to make it very clear that whether you > subclass or not makes absolutely no difference to tools validating the type > soundness of the code. > 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? -- Ivan ___ 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] __del__ is not called after creating a new reference
On 03/20, Nathaniel Smith wrote:
>
> Modern CPython, and all extant versions of PyPy and Jython, guarantee that
> __del__ is called at most once. MicroPython doesn't support user-defined
> __del__ methods.
>
> It's fine if the text wants to leave that open, but the current phrasing is
> pretty misleading IMO. I also read it as saying that __del__ would be
> called again if the object is collected again (which may or may not
> happen).
Yes, that is why I was confused. Just I could not believe nobody else noticed
this "bug" so I decided to check the sources and yes, the code looks very clear.
> But AFAICT there are actually zero implementations where this is
> true.
Probably this was mostly true until the commit 796564c2 ("Issue #18112: PEP
442 implementation (safe object finalization)."), python2 calls __del__ again.
> Probably worth a small edit :-)
Agreed. And it seems that not only me was confused,
http://doc.pypy.org/en/latest/cpython_differences.html says:
There are a few extra implications from the difference in the GC. Most
notably, if an object has a __del__, the __del__ is never called more
than once in PyPy; but CPython will call the same __del__ several times
if the object is resurrected and dies again.
Thanks to all!
Oleg.
___
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
Re: [Python-Dev] Translated Python documentation
2017-03-10 1:03 GMT+01:00 Victor Stinner : > FYI we are already working on a PEP with Julien Palard (FR) and INADA > Naoki (JP). We will post it when it will be ready ;-) Ok, Julien wrote the PEP with the help of Naoki and myself. He posted it on python-ideas for a first review: https://mail.python.org/pipermail/python-ideas/2017-March/045226.html The PEP is now very complete and lists all requested changes on the Python side. Let's discuss that on the python-ideas list ;-) Victor ___ 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
[Python-Dev] [RELEASE] Python 3.6.1 is now available
On behalf of the Python development community and the Python 3.6 release team, I would like to announce the availability of Python 3.6.1, the first maintenance release of Python 3.6. 3.6.0 was released on 2016-12-22 to great interest and now, three months later, we are providing the first set of bugfixes and documentation updates for it. Although it should be transparent to users of Python, 3.6.1 is the first release after some major changes to our development process so we ask users who build Python from source to be on the lookout for any unexpected differences. Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.1 here: https://www.python.org/downloads/release/python-361/ and its change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-1 The next maintenance release of Python 3.6 is expected to follow in about 3 months by the end of 2017-06. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily [email protected] -- [] ___ 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
