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 t
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 discussi
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 unexpe
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
>
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 im
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 change
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
appea
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.
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
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 postpon
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 co
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, a
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
-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
>
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
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 maintai
16 matches
Mail list logo
