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

[Miro Hrončok]

On 24. 01. 20 5:59, Ethan Furman wrote:
My understanding is that this postponement of removals is aimed at those who 
have just migrated to Python 3, not those who have already done it nor those who 
have 2/3 straddling code bases.


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 
Python 2.7, we ask them to support 3.9 from the same code base. Hence, they need 
to replace simple code:



from collections import Sequence

With either:

try:
from collections.abc import Sequence
except ImprotError:
# Python 2.7 doesn't have collections.abc
from collections import Sequence

Or:

from compatlib.moves.collections_abc import Sequence

In both cases, we move the burden of having a compatibility layer of some sort 
from one central location (Python 3.9 stdlib) to dozens (hundreds?) locations.


For those who have been on 3 for a while, 
updating to use the newer APIs for 3.9 vs 3.10 shouldn't make a difference. 



For Python 3 only projects? No, no difference.

Like-wise for those with 2/3 straddling code bases (we'll just need to add a few 
more things to our shims).


And our point is that because it's too early in 2020 to drop Python 2 code, it 
is better to encourage projects to update the code as Python 3 only in a year 
than to let them add more shims now just to hopefully remove them in couple months.


Anyone who hasn't supported/used Python 3 until now 
shouldn't have a problem with sticking with 3.8 until they are ready to make 
more adjustments, and those who have had to keep Python 2 around to run those 
applications/frameworks/whatevers will, I should think, be thrilled to use any 
Python 3 instead.  :-)


This does not affect projects who don't support Python 3 yet.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TFCAMIAJPCCPGCKC7KIWPCWZIMEWYKI6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 01/23/2020 07:02 PM, Robert Collins wrote:



On Fri, 24 Jan 2020 at 14:46, Ethan Furman mailto:et...@stoneleaf.us>> wrote:

On 01/23/2020 03:36 PM, Barry Warsaw wrote:
 > On Jan 23, 2020, at 14:03, Victor Stinner wrote:

 >> It's not only about specific changes, but more a discussion about a
 >> general policy to decide if a deprecated feature should stay until
 >> 3.10, or if it's ok to remove it in 3.9.
 >
 > 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.

I suspect anyone who's waited this long to switch to Python 3 will be okay 
with staying on 3.8 for a few years.

The issue isn't end users, it is projects who will then be incompatible with 3.10 for 
"a few years."


I'm sure you meant 3.9, since 3.10 would still have the removals.

My understanding is that this postponement of removals is aimed at those who 
have just migrated to Python 3, not those who have already done it nor those 
who have 2/3 straddling code bases.  For those who have been on 3 for a while, 
updating to use the newer APIs for 3.9 vs 3.10 shouldn't make a difference.  
Like-wise for those with 2/3 straddling code bases (we'll just need to add a 
few more things to our shims).  Anyone who hasn't supported/used Python 3 until 
now shouldn't have a problem with sticking with 3.8 until they are ready to 
make more adjustments, and those who have had to keep Python 2 around to run 
those applications/frameworks/whatevers will, I should think, be thrilled to 
use any Python 3 instead.  :-)

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BTTPBWELYSDWR36F4AAMD2RWEGV62CZE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Berg]

On Thu, 2020-01-23 at 18:36 -0800, Guido van Rossum wrote:
> Good question!
> 

It is, below mostly lamenting, so just to say my personal gut feeling
would be that it should probably be considered an "implementation
detail" that this used e.g. by most containers. But besides that it
leads to unexpected behaviour sometimes, I am not sure I have any
actual reasons. (Unless some typing JIT could run into it?)

> 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 -- which is reasonable).
> 
> 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.
> 
> We should probably also strongly recommend that __eq__ and __ne__ not
> do what math.nan does.


Another object similar to this are masked values (which e.g. pandas is
looking at). [2]
In their current definition, masked values would have to behave in a
similar way as numpy arrays, since `bool(NA == NA) -> bool(boolean_NA)`
is an error rather than `True`.
These objects are rare but hard to avoid completely, I guess...

> 
> However we cannot stop rich compare __eq__ implementations that
> return arrays of pairwise comparisons, since numpy does this. (And
> yes, it seems that this means that `x in y` is computed incorrectly
> if x is an array with such an __eq__ implementation and y is a tuple
> of such objects. I'm sure there's a big warning somewhere in the
> numpy docs about this, and I presume if y is a numpy array they make
> sure to do something better.)
> 

I somewhat doubt there is a big a warning currently...

In NumPy we actually stopped using `PyObject_RichCompareBool` within
`np.equal` a pretty long time ago [1]. IIRC we perceived it as a
bug.
However, as you said, object arrays which would succeed randomly [2]
were probably the more important motivation (rather than NaN). 

I do not think anyone has ever evaluated the performance impact of that
change though...

- Sebastian


[0] 
https://github.com/pandas-dev/pandas/pull/29597/files#diff-239ec95d581257ed256954660663b277R825-R827

[1] 
https://numpy.org/devdocs/release/1.13.0-notes.html#futurewarning-to-changed-behavior

[2] For those not familiar with NumPy, in NumPy: `[1, 2] == [1, 2]`
returns `[True, True]` but may here return True (if they are the same
object). The comparison should raise an error because [True, True] does
not generally have a truthiness defined but will succeed randomly.




> On Thu, Jan 23, 2020 at 5:33 PM 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.
> > 
> > This has visible consequences all over the place, but they don't
> > appear to be documented.  For example,
> > 
> > >>> import math
> > >>> ([math.nan] * 5).count(math.nan)
> > 5
> > 
> > despite that `math.nan == math.nan` is False.
> > 
> > It's usually clear which methods will be called, and when, but not
> > really here.  Any _context_ that calls PyObject_RichCompareBool()
> > under the covers, for an equality or inequality test, may or may
> > not
> > invoke __eq__ or __ne__, depending on whether the comparands are
> > the
> > same object.  Also any context that inlines these special cases to
> > avoid the overhead of calling PyObject_RichCompareBool() at all.
> > 
> > If it's intended that Python-the-language requires this, that needs
> > to
> > be documented.
> > 
> > Or if it's implementation-defined, then _that_ needs to be
> > documented.
> > 
> > Which isn't straightforward in either case, in part because
> > PyObject_RichCompareBool isn't a language-level concept.
> > 
> > This came up recently when someone _noticed_ the list.count(NaN)
> > behavior, and Victor made a PR to document it:
> > 
> > https://github.com/python/cpython/pull/18130
> > 
> > I'm pushing back, because documenting it _only_ for .count() makes
> > .count() seem unique in a way it isn't, and doesn't resolve the
> > fundamental issue:  is this language behavior, or implementation
> > behavior?
> > 
> > Which I don't want to argue about.  But you certainly should ;-)
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at 
> > https://mail.python.org/archives/list/python-dev@python.org/message/3ZAMS473HGHSI64XB3UV4XBICTG2DKVF/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To 

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

[Robert Collins]

On Fri, 24 Jan 2020 at 14:46, Ethan Furman  wrote:

> On 01/23/2020 03:36 PM, Barry Warsaw wrote:
> > On Jan 23, 2020, at 14:03, Victor Stinner wrote:
>
> >> It's not only about specific changes, but more a discussion about a
> >> general policy to decide if a deprecated feature should stay until
> >> 3.10, or if it's ok to remove it in 3.9.
> >
> > 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.
>
> I suspect anyone who's waited this long to switch to Python 3 will be okay
> with staying on 3.8 for a few years.
>

The issue isn't end users, it is projects who will then be incompatible
with 3.10 for "a few years."

-Rob
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/D7RVF7E7FKEZ46NW4YQWJLRCAGYESU7R/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 -- which is reasonable).

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.

We should probably also strongly recommend that __eq__ and __ne__ not do
what math.nan does.

However we cannot stop rich compare __eq__ implementations that return
arrays of pairwise comparisons, since numpy does this. (And yes, it seems
that this means that `x in y` is computed incorrectly if x is an array with
such an __eq__ implementation and y is a tuple of such objects. I'm sure
there's a big warning somewhere in the numpy docs about this, and I presume
if y is a numpy array they make sure to do something better.)

On Thu, Jan 23, 2020 at 5:33 PM 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.
>
> This has visible consequences all over the place, but they don't
> appear to be documented.  For example,
>
> >>> import math
> >>> ([math.nan] * 5).count(math.nan)
> 5
>
> despite that `math.nan == math.nan` is False.
>
> It's usually clear which methods will be called, and when, but not
> really here.  Any _context_ that calls PyObject_RichCompareBool()
> under the covers, for an equality or inequality test, may or may not
> invoke __eq__ or __ne__, depending on whether the comparands are the
> same object.  Also any context that inlines these special cases to
> avoid the overhead of calling PyObject_RichCompareBool() at all.
>
> If it's intended that Python-the-language requires this, that needs to
> be documented.
>
> Or if it's implementation-defined, then _that_ needs to be documented.
>
> Which isn't straightforward in either case, in part because
> PyObject_RichCompareBool isn't a language-level concept.
>
> This came up recently when someone _noticed_ the list.count(NaN)
> behavior, and Victor made a PR to document it:
>
> https://github.com/python/cpython/pull/18130
>
> I'm pushing back, because documenting it _only_ for .count() makes
> .count() seem unique in a way it isn't, and doesn't resolve the
> fundamental issue:  is this language behavior, or implementation
> behavior?
>
> Which I don't want to argue about.  But you certainly should ;-)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3ZAMS473HGHSI64XB3UV4XBICTG2DKVF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/X4ZIICG2EBMYPFUASI5TW4E6PIT2KR6M/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 01/23/2020 03:36 PM, Barry Warsaw wrote:

On Jan 23, 2020, at 14:03, Victor Stinner wrote:



It's not only about specific changes, but more a discussion about a
general policy to decide if a deprecated feature should stay until
3.10, or if it's ok to remove it in 3.9.


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.


I suspect anyone who's waited this long to switch to Python 3 will be okay with 
staying on 3.8 for a few years.

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5UHE5O2HVWDLEYP23HOLHFSAGCHDDHPL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Peters]

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.

This has visible consequences all over the place, but they don't
appear to be documented.  For example,

>>> import math
>>> ([math.nan] * 5).count(math.nan)
5

despite that `math.nan == math.nan` is False.

It's usually clear which methods will be called, and when, but not
really here.  Any _context_ that calls PyObject_RichCompareBool()
under the covers, for an equality or inequality test, may or may not
invoke __eq__ or __ne__, depending on whether the comparands are the
same object.  Also any context that inlines these special cases to
avoid the overhead of calling PyObject_RichCompareBool() at all.

If it's intended that Python-the-language requires this, that needs to
be documented.

Or if it's implementation-defined, then _that_ needs to be documented.

Which isn't straightforward in either case, in part because
PyObject_RichCompareBool isn't a language-level concept.

This came up recently when someone _noticed_ the list.count(NaN)
behavior, and Victor made a PR to document it:

https://github.com/python/cpython/pull/18130

I'm pushing back, because documenting it _only_ for .count() makes
.count() seem unique in a way it isn't, and doesn't resolve the
fundamental issue:  is this language behavior, or implementation
behavior?

Which I don't want to argue about.  But you certainly should ;-)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3ZAMS473HGHSI64XB3UV4XBICTG2DKVF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barry Warsaw]

On Jan 23, 2020, at 14:03, Victor Stinner  wrote:
> 
> I'm not sure of the meaning of "buried" here. What do you mean? We
> propose to revert 5 changes:
> 
> * Removed tostring/fromstring methods in array.array and base64 modules
> * Removed collections aliases to ABC classes
> * Removed fractions.gcd() function (which is similar to math.gcd())
> * Remove "U" mode of open(): having to use io.open() just for Python 2
> makes the code uglier
> * Removed old plistlib API: 2.7 doesn't have the new API
> 
>> Basically it isn't easy to discuss the things you want to revert here, 
>> especially since you grouped them all together. Are you planning to start 
>> separate conversations on the (I think) 5 things you want to change?
> 
> It's not only about specific changes, but more a discussion about a
> general policy to decide if a deprecated feature should stay until
> 3.10, or if it's ok to remove it in 3.9.

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.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XOK7KHU2TZLZ5TEE66LWCSG7P6SO7T3H/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

Le jeu. 23 janv. 2020 à 20:45, Brett Cannon  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 something that should mostly be a direct swap 
> after years of being asked to does not motivate in wanting to postpone one 
> more year for that project's benefit. ;) (And where did you get the download 
> stats on libraries.io? https://libraries.io/pypi/nose doesn't show any 
> download counts.)

Oh right, download stats can be found at: https://pypistats.org/packages/nose

Downloads last day: 150,272
Downloads last week: 824,557
Downloads last month: 3,077,860

150k downloads yesterday.


> Two, you buried the list of things you would like to revert and postpone to 
> Python 3.10. :)

I'm not sure of the meaning of "buried" here. What do you mean? We
propose to revert 5 changes:

* Removed tostring/fromstring methods in array.array and base64 modules
* Removed collections aliases to ABC classes
* Removed fractions.gcd() function (which is similar to math.gcd())
* Remove "U" mode of open(): having to use io.open() just for Python 2
makes the code uglier
* Removed old plistlib API: 2.7 doesn't have the new API


> Was this copied-and-pasted from somewhere, hence why you explain to us how to 
> use `-X dev`?

Well, use whatever you want to see DeprecationWarning, as soon as you
fix all of them in your project :-) PYTHONWARNINGS=default should be
fine as well.

IMO it's simpler to remind "-X dev" than using PYTHONWARNINGS=default.
By the way, -X dev and PYTHONWARNINGS=default shows more warnings than
just DeprecationWarning: they also show ImportWarning,
PendingDeprecationWarning and ResourceWarning. -X dev helps to make
your project ready for the next Python version.


> Basically it isn't easy to discuss the things you want to revert here, 
> especially since you grouped them all together. Are you planning to start 
> separate conversations on the (I think) 5 things you want to change?

I'm not sure of what you mean. Would you prefer one mail thread per revert?

It's not only about specific changes, but more a discussion about a
general policy to decide if a deprecated feature should stay until
3.10, or if it's ok to remove it in 3.9.

For example, another feature has been removed since we drafted this
email: "The encoding parameter of json.loads() has been removed." If
we follow the proposed policy, it should also be reverted.

It seems like the incompatible change causing most issues is the
collections change. We can try to produce statistics per change if you
prefer.

I understand that you disagree to revert changes, but you would prefer
to decide on a case by case basis.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GNJQP2NBLI6EZ2VKDE5UY3RMNP4JPTEZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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 something that should mostly be a direct swap after 
years of being asked to does not motivate in wanting to postpone one more year 
for that project's benefit. ;) (And where did you get the download stats on 
libraries.io? https://libraries.io/pypi/nose doesn't show any download counts.)

Two, you buried the list of things you would like to revert and postpone to 
Python 3.10. :) Was this copied-and-pasted from somewhere, hence why you 
explain to us how to use `-X dev`? Basically it isn't easy to discuss the 
things you want to revert here, especially since you grouped them all together. 
Are you planning to start separate conversations on the (I think) 5 things you 
want to change?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RQZR4J4JJJV3LBNMZZVACYVBRK6PUIUG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Comparing UUID objects to strings: why not?

[Michael Anckaert via Python-Dev]

Thank you all for your feedback, you all make very good points. I'll
take a deeper look at the resources given. 

Bernardo Sulzbach writes:

> I think that if the other object is a string, trying to get a UUID
> from it to compare UUIDs makes more sense than converting the UUID to
> string and comparing strings. Several different strings are perfectly
> fine for uniquely identifying the same UUID, so you seem to have
> gotten this bit backward, as Tal Einat pointed out.
>
> However, I strongly oppose automatic conversions, and, by proxy, this idea.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/AHACOVSPOVRJ257P2XSPPDA7I6AKE5IJ/
> Code of Conduct: http://python.org/psf/codeofconduct/


-- 
Michael Anckaert
+32 474 066 467
https://www.sinax.be
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3V7UWQSPDAIEVPWQJLE5MTFSZZE75A2H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Comparing UUID objects to strings: why not?

[Bernardo Sulzbach]

I think that if the other object is a string, trying to get a UUID
from it to compare UUIDs makes more sense than converting the UUID to
string and comparing strings. Several different strings are perfectly
fine for uniquely identifying the same UUID, so you seem to have
gotten this bit backward, as Tal Einat pointed out.

However, I strongly oppose automatic conversions, and, by proxy, this idea.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AHACOVSPOVRJ257P2XSPPDA7I6AKE5IJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Comparing UUID objects to strings: why not?

[Tal Einat]

On Thu, Jan 23, 2020 at 8:15 PM Andrew Svetlov  wrote:
>
> On Thu, Jan 23, 2020 at 5:46 PM Michael Anckaert via Python-Dev
>  wrote:
> >
> > Hello everyone
> >
> > I have a usecase where I'm comparing a UUID instance with string quite
> > often. A case where I have to convert the UUID instance to a string
> > using str(uuid_obj), leading to redundant code:
> >
> > if str(uuid_obj) == uuid:
> > # do stuff...
> >
> > In my experience I can't find a case where you wouldn't want the
> > implicit conversion to string before comparing a UUID with string. So
> > I would like to propose improving the __eq__ method of UUID to:
> >
> > def __eq__(self, other):
> > if isinstance(other, UUID):
> > return self.int == other.int
> > elif isinstance(other, str):
> > return str(self) == other
> > return NotImplemented
> >
> > Based on my testing and experience I don't think this is a breaking
> > change and would be a meaningful change to the way UUID works. Of course
> > please don't hesitate to change my view or point out any flaws in my
> > reasoning.
> >
> > If other people support this change I'd start the work of creating an
> > issue and PR to get this change implemented.
>
> -1
> Implicit type casting leads to hidden errors very often.

I also tend to be against this change, for the same general reason
that Andrew gave, but let me try to put that into more concrete terms.

In the specific case of UUIDs in the uuid module, equivalent UUIDs can
be constructed in various ways using the UUID constructor, including
using different string formats. For example, the following strings are
considered equivalent UUIDs:

"00010203-0405-0607-0809-0a0b0c0d0e0f"
"{00010203-0405-0607-0809-0a0b0c0d0e0f}"
"000102030405060708090a0b0c0d0e0f"
"urn:uuid:00010203-0405-0607-0809-0a0b0c0d0e0f"

For more examples, see the uuid module's tests:
https://github.com/python/cpython/blob/7142df5ea23b4ce0efb72746b4b3b65414e8dcb1/Lib/test/test_uuid.py#L29

Using string comparison for UUIDs would be significantly different
than what comparing uuid.UUID objects does. Therefore, making
UUID.__eq__() fall back to string comparison would be confusing, IMO
much more so than it would be helpful.


- Tal Einat
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZWS3EAQ55C3GUHRFPYHQWHG5O2OMDVWE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Comparing UUID objects to strings: why not?

[Andrew Svetlov]

-1
Implicit type casting leads to hidden errors very often.

On Thu, Jan 23, 2020 at 5:46 PM Michael Anckaert via Python-Dev
 wrote:
>
> Hello everyone
>
> I have a usecase where I'm comparing a UUID instance with string quite
> often. A case where I have to convert the UUID instance to a string
> using str(uuid_obj), leading to redundant code:
>
> if str(uuid_obj) == uuid:
> # do stuff...
>
> In my experience I can't find a case where you wouldn't want the
> implicit conversion to string before comparing a UUID with string. So
> I would like to propose improving the __eq__ method of UUID to:
>
> def __eq__(self, other):
> if isinstance(other, UUID):
> return self.int == other.int
> elif isinstance(other, str):
> return str(self) == other
> return NotImplemented
>
> Based on my testing and experience I don't think this is a breaking
> change and would be a meaningful change to the way UUID works. Of course
> please don't hesitate to change my view or point out any flaws in my
> reasoning.
>
> If other people support this change I'd start the work of creating an
> issue and PR to get this change implemented.
>
> --
> Michael Anckaert
> +32 474 066 467
> https://www.sinax.be
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/VXLJMWZRZLSFZRNHUITSLAV2O363WG5Q/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7S6IJLPHIJLMBVKHUBNKYZXWOOHMIGW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Comparing UUID objects to strings: why not?

[Michael Anckaert via Python-Dev]

Hello everyone

I have a usecase where I'm comparing a UUID instance with string quite
often. A case where I have to convert the UUID instance to a string
using str(uuid_obj), leading to redundant code:

if str(uuid_obj) == uuid:
# do stuff...

In my experience I can't find a case where you wouldn't want the
implicit conversion to string before comparing a UUID with string. So
I would like to propose improving the __eq__ method of UUID to:

def __eq__(self, other):
if isinstance(other, UUID):
return self.int == other.int
elif isinstance(other, str):
return str(self) == other
return NotImplemented

Based on my testing and experience I don't think this is a breaking
change and would be a meaningful change to the way UUID works. Of course
please don't hesitate to change my view or point out any flaws in my
reasoning. 

If other people support this change I'd start the work of creating an
issue and PR to get this change implemented. 

-- 
Michael Anckaert
+32 474 066 467
https://www.sinax.be
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VXLJMWZRZLSFZRNHUITSLAV2O363WG5Q/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

Hi,

Python 3.9 introduces many small incompatible changes which broke tons
of Python projects, including popular projects, some of them being
unmaintained but still widely used (like nose, last release in 2015).

Miro and me consider that Python 3.9 is pushing too much pressure on
projects maintainers to either abandon Python 2.7 right now (need to
update the CI, the documentation, warn users, etc.), or to introduce a
*new* compatibility layer to support Python 3.9: layer which would be
dropped as soon as Python 2.7 support will be dropped (soon-ish).

Python 3.9 is too early to accumulate so many incompatible changes on
purpose, some incompatible changes like the removal of collections
aliases to ABC should be reverted, and reapplied on Python 3.10.
Python 3.9 would be the last release which still contain compatibility
layers for Python 2.7.

Said differently, we request to maintain the small compatibility layer
in Python for one more cycle, instead of requesting every single
project maintainer to maintain it on their side. We consider that the
general maintenance burden is lower if it's kept in Python for now.


== Fedora COPR notify packages broken by Python 3.9 ==

In Python 3.9, Victor introduced tons of incompatible changes at the
beginning of the devcycle. His plan was to push as many as possible,
and later decide what to do... This time has come :-) He wrote PEP 606
"Python Compatibility Version" and we wrote PEP 608 "Coordinated
Python release", but both have been rejected. At least, it seems like
most people agreed that having a CI to get notified of broken projects
should help.

We are updating the future Fedora 33 to replace Python 3.8 with Python
3.9. We are using a tool called "COPR" which is like a sandbox and can
be seen as the CI discussed previously. It rebuilds Fedora using
Python 3.9 as /usr/bin/python3 (and /usr/bin/python !). We now have a
good overview of broken packages and which incompatible changes broke
most packages.

https://fedoraproject.org/wiki/Changes/Python3.9
- Describes the Fedora change.

https://copr.fedorainfracloud.org/coprs/g/python/python3.9/monitor/
- Has package failures. Some packages fail because of broken dependencies.

https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON39
- Has open Python 3.9 bug reports for Fedora packages. Some problems
have been fixed upstream already before reaching Fedora, most are only
fixed when the Fedora maintainers report the problems back to upstream
maintainers.

Right now, there are 150+ packages broken by Python 3.9 incompatible changes.


== Maintenance burden ==

Many Python projects have not yet removed Python 2 support and Python
2 CI. It's not that they would be in the "we will not drop Python 2
support ever" camp, it's just that they have not done it yet. Removing
Python 2 compatibility code from the codebase and removing it from the
documentation and metadata and CI is a boring task, doesn't bring
anything to users, and it might take a new major release of the
library. At this point, we are very early in 2020 to expect most
projects to have already done this.

At the same time, we would like them to support Python 3.9 as soon in
the release cycle as possible. By removing Python 2 compatibility
layers from the 3.9 standard library, we are forcing the projects
maintainers to re-invent their own compatibility layers and copy-paste
stuff like this around. Example:

try:
from collections.abc import Sequence
except ImprotError:
# Python 2.7 doesn't have collections.abc
from collections import Sequence

While if we remove collections.Sequence in 3.10, they will face this
decision early in 2021 and they will simply fix their code by adding
".abc" at the proper places, not needing any more compatibility
layers. Of course, there will be projects that will still have
declared Python 2 support in 2021, but it will arguably not be that
many.

While it's certainly tempting to have "more pure" code in the standard
library, maintaining the compatibility shims for one more release
isn't really that big of a maintenance burden, especially when
comparing with dozens (hundreds?) of third party libraries essentially
maintaining their own.

An good example of a broken package is the nose project which is no
longer maintained (according to their website): the last release was
in 2015. It remains a very popular test runner. According to
libraries.io, it has with 3 million downloads per month, 41.7K
dependent repositories and 325 dependent packages. We patched nose in
Fedora to fix Python 3.5, 3.6, 3.8 and now 3.9 compatibility issues.
People installing nose from PyPI with "pip install" get the
unmaintained flavor which is currently completely broken on Python
3.9.

Someone should take over the nose project and maintain it again, or
every single project using nose should pick another tool (unittest,
nose2, pytest, whatever else). Both options will take a lot of time.


== Request to revert some incompatible changes ==

See