[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 8:43 PM, Tim Peters wrote: [Terry Reedy ] ]& skipping all the parts I agree with] ... Covered by "For user-defined classes which do not define __contains__() but do define __iter__(), x in y is True if some value z, for which the expression x is z or x == z is true, is produced

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Terry Reedy ] ]& skipping all the parts I agree with] > ... > Covered by "For user-defined classes which do not define __contains__() > but do define __iter__(), x in y is True if some value z, for which the > expression x is z or x == z is true, is produced while iterating over y. > " in > >

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 5:29 PM, Tim Peters wrote: [Terry Reedy ] ... It is, in the section on how to understand and use value comparison *operators* ('==', etc.). https://docs.python.org/3/reference/expressions.html#value-comparisons First "The default behavior for equality comparison (== and !=) is

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Tim] >> I think it needs more words, though, to flesh out what about this is >> allowed by the language (as opposed to what CPython happens to do), >> and to get closer to what Guido is trying to get at with his >> "*implicit* calls". For example, it's at work here, but there's not a >> built-in

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

25.01.20 00:29, Tim Peters пише: I think it needs more words, though, to flesh out what about this is allowed by the language (as opposed to what CPython happens to do), and to get closer to what Guido is trying to get at with his "*implicit* calls". For example, it's at work here, but there's

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Sat, Jan 25, 2020 at 9:40 AM Tim Peters wrote: > I think it needs more words, though, to flesh out what about this is > allowed by the language (as opposed to what CPython happens to do), > and to get closer to what Guido is trying to get at with his > "*implicit* calls". For example, it's at

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Terry Reedy ] > ... > It is, in the section on how to understand and use value comparison > *operators* ('==', etc.). > https://docs.python.org/3/reference/expressions.html#value-comparisons > > First "The default behavior for equality comparison (== and !=) is based > on the identity of the

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

23.01.20 17:20, Victor Stinner пише: > * Removed collections aliases to ABC classes Adding loud warning was one of largest compatibility breaking changes in 3.8, because many active projects treat warnings in tests as errors. I had doubts about removing them. On one side, they were deprecated

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Inada Naoki ] > FWIW, (list|tuple).__eq__ and (list|tuple).__contains__ uses it too. > It is very important to compare recursive sequences. > > >>> x = [] > >>> x.append(x) > >>> y = [x] > >>> z = [x] > >>> y == z > True That's a visible consequence, but I'm afraid this too must be considered an

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 7:09 AM, Steven D'Aprano wrote: On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote: On 1/24/2020 3:36 AM, Victor Stinner wrote: CPython current behavior rely on the fact that it's possible to get the memory address of an object. No, this behavior relies on the

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 7:09 AM, Steven D'Aprano wrote: On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote: On 1/24/2020 3:36 AM, Victor Stinner wrote: CPython current behavior rely on the fact that it's possible to get the memory address of an object. No, this behavior relies on the

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Le ven. 24 janv. 2020 à 19:35, Brett Cannon a écrit : > I'm also okay with a one-time delay in removals that are problematic for code > trying to get off of Python 2.7 this year and might not quite cut it before > 2021 hits. I'm sure some people will be caught off-guard once 3.9b1 comes out >

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Le ven. 24 janv. 2020 à 19:28, Brett Cannon a écrit : > (...) otherwise I could be reading most of that email as if you're suggesting > we bring back the print statement or something. ;) By the way, about adding back print statement... nah, I'm just kidding :-D Victor

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Eric V. Smith wrote: > On 1/24/2020 9:14 AM, Miro Hrončok wrote: > > On 24. 01. 20 14:02, Eric V. Smith wrote: > > I think the concern is that with removing so > > many deprecated > > features, we're effectively telling libraries that if they want to > > support 3.9, they'll have stop supporting

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Victor Stinner wrote: > Le jeu. 23 janv. 2020 à 20:45, Brett Cannon br...@python.org a écrit : > > Two pieces of feedback on this. One, nose is a bad > > example because that project has been telling people for years to switch to > > nose2 so the > > fact that people have still not switched

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2020-01-17 - 2020-01-24) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7285 (+17) closed 43910 (+55) total 51195 (+72) Open issues

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

Terry Reedy wrote: > On 1/24/2020 4:23 AM, Paul Moore wrote: > > On Fri, 24 Jan 2020 at 02:36, Guido van Rossum gu...@python.org wrote: > > I'm tempted to declare this > > implementation-defined behavior -- implicit calls to __eq__ and __ne__ > > may be skipped if both sides are the same object

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On Fri, Jan 24, 2020 at 12:12 AM Serhiy Storchaka wrote: > I consider breaking unmaintained code is an additional benefit of > removing deprecated features. > I'd like to warn against this attitude (even though in the past I've occasionally said such things). I now think core Python should not

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 4:47 AM Steven D'Aprano wrote: > On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote: > > On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano > wrote: > > > > > > The only thing I'm unsure of here is whether direct use of the `==` and > > > `!=` operators are

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 3:45 AM Steven D'Aprano wrote: > On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev > wrote: > > > >I'm tempted to declare this implementation-defined behavior -- > *implicit* > > >calls to __eq__ and __ne__ *may* be skipped if both sides are the same >

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 12:36 AM Victor Stinner wrote: > Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a > écrit : > > I think this started with a valuable optimization for `x in `. I > don't know if that was ever carefully documented, but I remember that it > was discussed a few times (and

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 01/24/2020 05:02 AM, Eric V. Smith wrote: On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote: On Fri, 24 Jan 2020 at 10:05, Victor Stinner wrote: The proposal is to give one year to project maintainers to drop Python 2.7 support, since Python 2.7 end of support just happened a few weeks ago

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On Fri, 24 Jan 2020 at 14:14, Miro Hrončok wrote: > > On 24. 01. 20 14:02, Eric V. Smith wrote: > > I think the concern is that with removing so many deprecated features, we're > > effectively telling libraries that if they want to support 3.9, they'll have > > stop supporting 2.7. And many

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 1/24/2020 9:14 AM, Miro Hrončok wrote: On 24. 01. 20 14:02, Eric V. Smith wrote: I think the concern is that with removing so many deprecated features, we're effectively telling libraries that if they want to support 3.9, they'll have stop supporting 2.7. And many library authors aren't

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, 24 Jan 2020 at 11:15, Terry Reedy wrote: > > On 1/24/2020 4:23 AM, Paul Moore wrote: > > We could add an extra clause here: """As an optimisation, when the > > implementation *implicitly* compares two values for equality (for > > example, in list comparison or `list.count`) it is allowed

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 24. 01. 20 14:02, Eric V. Smith wrote: On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote: On Fri, 24 Jan 2020 at 10:05, Victor Stinner > wrote: The proposal is to give one year to project maintainers to drop Python 2.7 support, since Python 2.7 end of support

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote: On Fri, 24 Jan 2020 at 10:05, Victor Stinner > wrote: The proposal is to give one year to project maintainers to drop Python 2.7 support, since Python 2.7 end of support just happened a few weeks ago

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote: > On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote: > > > > The only thing I'm unsure of here is whether direct use of the `==` and > > `!=` operators are included as "implicit calls" to the dunders. I > > *think* I understand

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

24.01.20 13:57, Chris Angelico пише: Are there any non-container uses where this comes up? Can the rule be codified simply as that container membership, in all core/stdlib types, is defined by "x is y or x == y"? Also a membership test for iterators (which is already explicitly documented).

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote: > On 1/24/2020 3:36 AM, Victor Stinner wrote: > >CPython current behavior rely on the fact that it's possible to get > >the memory address of an object. > > No, this behavior relies on the language specification that all objects >

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote: > > The only thing I'm unsure of here is whether direct use of the `==` and > `!=` operators are included as "implicit calls" to the dunders. I > *think* I understand Guido's intention, but I'm not sure: > > * x == y MUST call `__eq__` > > *

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev wrote: > >I'm tempted to declare this implementation-defined behavior -- *implicit* > >calls to __eq__ and __ne__ *may* be skipped if both sides are the same > >object depending on the whim of the implementation. > > This

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 4:23 AM, Paul Moore wrote: On Fri, 24 Jan 2020 at 02:36, Guido van Rossum wrote: I'm tempted to declare this implementation-defined behavior -- *implicit* calls to __eq__ and __ne__ *may* be skipped if both sides are the same object depending on the whim of the implementation.

[Python-Dev] Re: SWIFT Confirmation and request for Updated Statement for DEC invoice

Sir, Please note that and we are Transferring payment again to your Designated bank As advised earlier. Kindly see attached covering letter with Bank Swift for follow up with your bank. Also see below specification Of payment breakdown. USD 3,146.05 USD 28,550.00 Please kindly confirm

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 3:36 AM, Victor Stinner wrote: Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a écrit : I think this started with a valuable optimization for `x in `. I don't know if that was ever carefully documented, but I remember that it was discussed a few times (and IIRC Raymond was

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On Fri, 24 Jan 2020 at 10:05, Victor Stinner wrote: > > The proposal is to give one year to project maintainers to drop Python > 2.7 support, since Python 2.7 end of support just happened a few weeks > ago (2020-01-01). > IMO creating this kind of "gray areas" in support and deprecation issues

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Thu, Jan 23, 2020 at 07:29:58PM -0600, Tim Peters wrote: > PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x > and y are the same object, then equality comparison returns True and > inequality False. No attempt is made to execute __eq__ or __ne__ > methods in those cases. >

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 3:12 AM, Victor Stinner wrote: IMO it's a good optimization to skip __eq__() when id(x) == id(y). From a higher level viewpoint, what is being skipped is literally doing 'x == y'. But it can be surprising, so I just would like to document it somewhere. It is, in the section

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Adding Python 3.9 and dropping Python 2.7 support are two different things, but Python 3.9 somehow "enforces" to do both at the same time. The proposal is to give one year to project maintainers to drop Python 2.7 support, since Python 2.7 end of support just happened a few weeks ago

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On Fri, 24 Jan 2020 at 08:54, Victor Stinner wrote: > > The change is that Python 2.7 is no longer supported (since 2020-01-01). However the assertion here seems to be that some people are unprepared for this (which seems to me like it's their problem, not ours). Features getting deprecated in

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 24.01.2020 5:36, Guido van Rossum wrote: Good question! I think this started with a valuable optimization for `x in `. I don't know if that was ever carefully documented, but I remember that it was discussed a few times (and IIRC Raymond was adamant that this should be so optimized --

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, 24 Jan 2020 at 02:36, Guido van Rossum wrote: > I'm tempted to declare this implementation-defined behavior -- *implicit* > calls to __eq__ and __ne__ *may* be skipped if both sides are the same object > depending on the whim of the implementation. This sounds reasonable to me. It

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

24.01.20 10:29, Serhiy Storchaka пише: Even Python implementations like collections.abc.Sequence and collections.abc.Mapping were changed to use `x is y or x == y` instead of just `x == y` few versions ago. https://bugs.python.org/issue26915 ___

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On Fri, Jan 24, 2020 at 7:40 PM Victor Stinner wrote: > > The change is that Python 2.7 is no longer supported (since 2020-01-01). > Which means that it's now okay to remove things, correct? Starting with 3.9, it's no longer necessary to maintain compatibility with 2.7? ChrisA

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

The change is that Python 2.7 is no longer supported (since 2020-01-01). Victor Le ven. 24 janv. 2020 à 09:19, Chris Angelico a écrit : > > On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner wrote: > > We kept a compatibility layer with Python 2 on purpose, PEP 4 says: > > > > "In order to

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a écrit : > I think this started with a valuable optimization for `x in `. I don't > know if that was ever carefully documented, but I remember that it was > discussed a few times (and IIRC Raymond was adamant that this should be so > optimized

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 5:24 PM Victor Stinner wrote: > > You're right that it's not only about list.count(). > > list.count(), list.index(), tuple.count() and tuple.index() all > consider that two elements are equal if id(x) == id(y): > FWIW, (list|tuple).__eq__ and (list|tuple).__contains__

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 24.01.2020 11:08, Serhiy Storchaka wrote: 23.01.20 17:20, Victor Stinner пише: Incompatible changes which require "if : (...) else: (...)" or "try: except (...): ": * Removed tostring/fromstring methods in array.array and base64 modules * Removed collections aliases to ABC classes *

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

24.01.20 03:29, Tim Peters пише: If it's intended that Python-the-language requires this, that needs to be documented. I think it is already documented somewhere. Even Python implementations like collections.abc.Sequence and collections.abc.Mapping were changed to use `x is y or x == y`

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

24.01.20 01:36, Barry Warsaw пише: Given that we’ve changed the release cadence to one major release per year, it doesn’t seem that much of a burden to revert and carry these changes forward into Python 3.10. And if it helps with the migration off of Python 2.7, then +1 from me. There are

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

You're right that it's not only about list.count(). IMO it's a good optimization to skip __eq__() when id(x) == id(y). But it can be surprising, so I just would like to document it somewhere. For example, in __eq__() method documentation:

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner wrote: > We kept a compatibility layer with Python 2 on purpose, PEP 4 says: > > "In order to facilitate writing code that works in both Python 2 & 3 > simultaneously, any module that exists in both Python 3.5 and Python > 2.7 will not be removed

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

23.01.20 17:20, Victor Stinner пише: Incompatible changes which require "if : (...) else: (...)" or "try: except (...): ": * Removed tostring/fromstring methods in array.array and base64 modules * Removed collections aliases to ABC classes * Removed fractions.gcd() function (which is similar

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Le ven. 24 janv. 2020 à 08:37, Miro Hrončok a écrit : > No, the motivation to pospone the changes to 3.10 are projects that alrady > support both 2 and 3 at the same time, with or without compatibility libraries > like six. Before they had anough time to make the necessary actions to abandon >