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

[Nick Coghlan]

On Wed, 4 Mar 2020 at 23:09, Victor Stinner  wrote:
> By the way, I also added a new "You should check for
> DeprecationWarning in your code" section to "What's New In Python 3.9"
> document, to strongly advice users to check for deprecation warnings
> in their code:
> https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code

That's a good idea.

Having a section explaining how to check for deprecation warnings, and
listing out some notable ones that are expected to become errors in
the next release would actually make sense as a routine feature of the
What's New document.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/M72VCFHBU6CHZQHFH6DASQG2FEVOCFAS/
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]

Hi,

I proposed a second change to restore the "U" open() mode (universal newlines):
https://github.com/python/cpython/pull/18767

Again, it's only kept in Python 3.9 to ease migration from Python 2,
but will be removed in Python 3.10.

By the way, I also added a new "You should check for
DeprecationWarning in your code" section to "What's New In Python 3.9"
document, to strongly advice users to check for deprecation warnings
in their code:
https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code

Victor

Le mar. 18 févr. 2020 à 12:37, Victor Stinner  a écrit :
>
> Hi,
>
> I created an issue:
>
> "Keep deprecated features in Python 3.9 to ease migration from Python
> 2.7, but remove in Python 3.10"
> https://bugs.python.org/issue39674
>
> And proposed a first pull request to add again collections.Mapping:
>
> https://github.com/python/cpython/pull/18545
>
> Victor
___
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/KT4B2C3EFEB6MXG55OHGCKN7CRVKI4SX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Dong-hee Na]

> And proposed a first pull request to add again collections.Mapping:

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

FYI, this patch is adding a fixer to handling abstract base classes.
It will be helpful for the migration to new changes.
I hope someone reviews this.


2020년 2월 18일 (화) 오후 8:44, Victor Stinner 님이 작성:
>
> Hi,
>
> I created an issue:
>
> "Keep deprecated features in Python 3.9 to ease migration from Python
> 2.7, but remove in Python 3.10"
> https://bugs.python.org/issue39674
>
> And proposed a first pull request to add again collections.Mapping:
>
> https://github.com/python/cpython/pull/18545
>
> Victor
>
> Le jeu. 23 janv. 2020 à 16:20, Victor Stinner  a écrit :
> >
> > 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 

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

[Victor Stinner]

Hi,

I created an issue:

"Keep deprecated features in Python 3.9 to ease migration from Python
2.7, but remove in Python 3.10"
https://bugs.python.org/issue39674

And proposed a first pull request to add again collections.Mapping:

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

Victor

Le jeu. 23 janv. 2020 à 16:20, Victor Stinner  a écrit :
>
> 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 

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

[Matěj Cepl]

On 2020-02-04, 01:00 GMT, Brett Cannon wrote:
> I think people also forget that prior to worrying about 
> maintaining backwards-compatibility with Python 2 we 
> deprecated for a release and then we removed (so an 18 month 
> deprecation period).

But then you mustn’t filter out deprecation warnings. And yes, 
we have to relearn that deprecation warning means the incoming 
doom, not something to ignore.

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Thou shalt not nede to be afrayed for any bugges by night.
  -- Coverdale's 1535 translation of Psalm 91
 (or Christopher Higley's 1972 thesis explaining why
  programmers' are nocturnal beasts)
___
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/JM6X6A4E5YEYSZWSVM5CMNDSUOAHJ2A5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mike Miller]

On 2020-02-04 14:40, Paul Moore wrote:
>> The answer to that concern is to not break compatibility in the first place,
>> and/or revert it when the mistake is discovered.  It happens.
>
> That sounds to me like an argument for stagnation. We already take
> backwards compatibility very seriously. If you're suggesting that we
> don't even have the option of deprecating things, then I'm not sure
> how you expect the language to evolve.

No, I chose the wrong phrasing there.  Have been arguing for deprecations to 
occur on schedule but removals to occur later.  By "not break compatibility…" I 
meant not to break it in a large, destructive manner.  Small ones, sure.



> The point has already been made that "keeping code around but
> deprecated" isn't the problem, it's bug triage, telling people who
> report problems with deprecated code that "this is not going to be
> fixed", educating people who copy/paste old and deprecated code and
> wonder why they are now getting warnings with it, etc. I think it's
> probably up to the core devs (who do the work) to judge what is an
> "undue burden", but if you do want to try to judge it, please take all
> of those extra tasks into account when reckoning up.

This happens already and won't go away.  I'm arguing that a *very* predictable 
release process helps and doesn't hurt in this department, resulting in fewer 
questions.  Instead of every release is a unique snowflake to be considered. 
Still have questions?  Go to FAQ #42.



> Restricting compatibility breaks to the major version
> isn't that important in my experience. IMO, the version number isn't
> anywhere near as important as the *process* of handling backward

It matters, when say Ubuntu drops X.4 when X.6 comes out and X.6 isn't backwards 
compatible.  You get forced to update or find one of the various workarounds.  I 
argue this should happen less frequently at predictable times.



> No, it's that conserving the *extremely* limited resource that is
> freely donated, volunteer core developer time is essential if we want
> to have a viable core development team at all.


Sorry, didn't mean that part as an attack, rather an illustration of the 
tradeoff being made.  Now if PSF needs help to build a more predictable release 
process, well then, by all means ask.  But that can't happen until the decision 
is made to do it.


-Mike
___
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/KJPMNIXB3GX6GEOHTXA324DFJBSJFKHO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On Tue, 4 Feb 2020 at 22:10, Mike Miller  wrote:
>
> On 2020-02-04 12:10, Brett Cannon wrote:
> > Please be careful making that claim. Over my 16 years of helping manage 
> > this project I can tell you that claim is not universally true no matter 
> > how small and simple you think something is.
>
> The answer to that concern is to not break compatibility in the first place,
> and/or revert it when the mistake is discovered.  It happens.

That sounds to me like an argument for stagnation. We already take
backwards compatibility very seriously. If you're suggesting that we
don't even have the option of deprecating things, then I'm not sure
how you expect the language to evolve.

> As mentioned, significant breaks are now discouraged.  The code is already
> written, so I'd argue keeping it deprecated potentially a few years extra in a
> regular process is not an undue burden.

The point has already been made that "keeping code around but
deprecated" isn't the problem, it's bug triage, telling people who
report problems with deprecated code that "this is not going to be
fixed", educating people who copy/paste old and deprecated code and
wonder why they are now getting warnings with it, etc. I think it's
probably up to the core devs (who do the work) to judge what is an
"undue burden", but if you do want to try to judge it, please take all
of those extra tasks into account when reckoning up.

> > Python predates semver. Assume every feature/minor release potentially has 
> > a breaking change and we have (hopefully) been raising warnings to the user 
> > for the past two years about the breaking change coming.
>
> Hmm, was thinking about MS-DOS when I wrote that.  Still, I don't think this a
> good system having breaking changes in the minor version number.  It's not
> traditional and it's not newfangled either, it's relatively unique.

I have seen many systems that have breaking changes in the minor
version, as you describe it. (Java 1.1 to Java 1.4 are a good example
- so good that they "rebranded" the minor version as the major version
with 1.5!). Restricting compatibility breaks to the major version
isn't that important in my experience. IMO, the version number isn't
anywhere near as important as the *process* of handling backward
compatibility and giving users a good transition path. Knowing what
the rules being followed are is the most important thing - and people
trying to claim that semver concepts apply to a system that doesn't
use it, just because the version number syntax looks like semver, is
one of the worst ways to confuse the message IMO.

> On that note, just noticed that Wikipedia has its own section for Python under
> the "Software Versioning" article:
>
>  The PSF has published PEP 440 -- Version Identification and Dependency
>  Specification,[16] outlining their own flexible (complicated) scheme, 
> that
>  defines an epoch segment, a release segment, pre-release and post-release
>  segments and a development release segment.
>
>  https://en.wikipedia.org/wiki/Software_versioning#Python

PEP 440 is not about Python's own version scheme, it's a standard for
versioning Python *packages* that are published on PyPI and managed by
tools like pip. It's complicated because it has to allow for many
different legacy versioning schemes which were in use by existing
projects when the PEP was defined. Ideally we would have chosen a
simpler scheme, but that would have required breaking many existing
projects' version schemes, so we chose not to do that. So it's
actually a great demonstration of how not being able to deprecate old
usages *adds* complexity and maintenance burden.

But it's an irrelevant side issue when talking about the Python
language version itself, as PEP 440 doesn't apply to that.

> The main argument here seems to be it this uncommon versioning scheme saves 
> core
> developer time, (unsaid) at the expense of dev or end-user time.  As there are
> probably a million end-users per Python contributor, I argue this is not a 
> good
> tradeoff to make.

No, it's that conserving the *extremely* limited resource that is
freely donated, volunteer core developer time is essential if we want
to have a viable core development team at all. If in doing so, we need
to have a controlled deprecation process that places some of the
burden of keeping up to date on end users who benefit for no cost from
the huge amount of donated software and support that makes up what
people think of as "Python", then that should be an entirely
acceptable trade-off.

Paul
___
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/37K2HWAY5LXLF6W2HKUL5T46JBB4DVWQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mike Miller]

On 2020-02-04 12:10, Brett Cannon wrote:

Please be careful making that claim. Over my 16 years of helping manage this 
project I can tell you that claim is not universally true no matter how small 
and simple you think something is.


The answer to that concern is to not break compatibility in the first place, 
and/or revert it when the mistake is discovered.  It happens.


As mentioned, significant breaks are now discouraged.  The code is already 
written, so I'd argue keeping it deprecated potentially a few years extra in a 
regular process is not an undue burden.



Python predates semver. Assume every feature/minor release potentially has a 
breaking change and we have (hopefully) been raising warnings to the user for 
the past two years about the breaking change coming.


Hmm, was thinking about MS-DOS when I wrote that.  Still, I don't think this a 
good system having breaking changes in the minor version number.  It's not 
traditional and it's not newfangled either, it's relatively unique.


On that note, just noticed that Wikipedia has its own section for Python under 
the "Software Versioning" article:


The PSF has published PEP 440 -- Version Identification and Dependency
Specification,[16] outlining their own flexible (complicated) scheme, that
defines an epoch segment, a release segment, pre-release and post-release
segments and a development release segment.

https://en.wikipedia.org/wiki/Software_versioning#Python


The main argument here seems to be it this uncommon versioning scheme saves core 
developer time, (unsaid) at the expense of dev or end-user time.  As there are 
probably a million end-users per Python contributor, I argue this is not a good 
tradeoff to make.


-Mike
___
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/626TBIIMXHVQR4RQK76T4VX622WW5SOE/
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]

Mike Miller wrote:
> On 2020-02-03 17:00, Brett Cannon wrote:
> > Until you're being asked to maintain all of that for
> > a decade. We paid a major price keeping Python 2 alive for over a decade. 
> > Now I'm not
> > saying it wasn't the right thing to do considering what we changed, but for 
> > the stuff we
> > are talking about removing it doesn't require a massive rewrite on the 
> > behalf of users.
> > And we know from experience anything that is left in will get used no 
> > matter how loudly we
> > try to broadcast that fact (and we know people still do not have a habit of 
> > running their
> > code with warnings turned on).
> > Potentially up to a decade, often not.
> We seem to agree that these are most likely minor things like duplicate 
> import 
> paths and such.  The maintenance burden is low on these items.

Please be careful making that claim. Over my 16 years of helping manage this 
project I can tell you that claim is not universally true no matter how small 
and simple you think something is.

>  Also, due to 
> skittishness, removals have drug out to five plus releases anyway.

That has been due to Python 2 compatibility which is about to no longer be a 
concern. Prior to Python 2 this was not the case.

>  So, why the 
> aversion to formalizing the process, instead of "winging it" every release?

There is work to formalize it in PEP 387. We are just dealing with an odd case 
of Python 2 compatibility which is a one-off situation.

>  Why 
> force devs/end-users to maintain state about what release is compatible or 
> waste 
> time on investigation?
> Really, this was solved decades ago.  Everyone knows what to do when a major 
> version number changes.  Other language platforms are not afraid to change 
> them, 
> likely because the breaks were typically minor and not break-the-world 
> events. 

Python predates semver. Assume every feature/minor release potentially has a 
breaking change and we have (hopefully) been raising warnings to the user for 
the past two years about the breaking change coming.
___
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/SUMQIDIEYI7CTWOLF3EY5CR432NJH7NN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mike Miller]

On 2020-02-03 17:00, Brett Cannon wrote:

Until you're being asked to maintain all of that for a decade. We paid a major 
price keeping Python 2 alive for over a decade. Now I'm not saying it wasn't 
the right thing to do considering what we changed, but for the stuff we are 
talking about removing it doesn't require a massive rewrite on the behalf of 
users. And we know from experience anything that is left in will get used no 
matter how loudly we try to broadcast that fact (and we know people still do 
not have a habit of running their code with warnings turned on).


Potentially up to a decade, often not.

We seem to agree that these are most likely minor things like duplicate import 
paths and such.  The maintenance burden is low on these items.  Also, due to 
skittishness, removals have drug out to five plus releases anyway.  So, why the 
aversion to formalizing the process, instead of "winging it" every release?  Why 
force devs/end-users to maintain state about what release is compatible or waste 
time on investigation?


Really, this was solved decades ago.  Everyone knows what to do when a major 
version number changes.  Other language platforms are not afraid to change them, 
likely because the breaks were typically minor and not break-the-world events. 
Just like we're talking about here.


More broadly, an agile cadence is great for innovative apps, not so great for 
mature platforms.  Platforms are supposed to provide stability and 
predictability, and the popular ones do.


-Mike
___
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/S7JXBK7OA75GVIVHDWOPMLALMCJJKGZN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mike Miller]

On 2020-02-04 04:16, Rhodri James wrote:
I think that just enables laziness.  "We don't need to worry about the 
deprecations, nothing is going to happen for years yet," is more or less what 
happened with the Python2 to Python3 shift.  People naturally enjoy adding shiny 
new features to their projects over maintenance.


That's an uncharitable interpretation.  Not everyone has the luxury of fixing 
broken code every year.  (New release schedule)  It's not how most of the 
industry works either.



As a refinement to the idea above, perhaps a sub rule could be added:

   - No deprecations should appear in a X.9 release to give folks time
 to prepare.


That feels like a very bad idea indeed.  If you don't tell people things are 
going away, they definitely won't prepare for that.


This point is not suggesting to break things and "not tell anyone."  Rather to 
avoid any compatibility breaks on the ultimate release of a series to give folks 
a minimum of two years to react.


-Mike
___
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/2WSJKFRERIBZPYIADKEJFZTEKLL5D2HS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rhodri James]

On 03/02/2020 22:06, Mike Miller wrote:


On 2020-02-03 01:50, Petr Viktorin wrote:
When the changes are rolled out gradually across minor releases, those 
that cause unforeseen trouble in real-world code can be identified in 
the alphas/betas, and rethought/reverted if necessary.



To be clear, my suggestion was to maintain gradual deprecations and 
warnings, but have a single removal event at the start of a new version 
major number.  So there will be many years of betas and releases to 
haggle over.


I think that just enables laziness.  "We don't need to worry about the 
deprecations, nothing is going to happen for years yet," is more or less 
what happened with the Python2 to Python3 shift.  People naturally enjoy 
adding shiny new features to their projects over maintenance.



As a refinement to the idea above, perhaps a sub rule could be added:

   - No deprecations should appear in a X.9 release to give folks time
     to prepare.


That feels like a very bad idea indeed.  If you don't tell people things 
are going away, they definitely won't prepare for that.


--
Rhodri James *-* Kynesim Ltd
___
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/43S4KEWSIYTZ7HBZ6KBYEMFZG6KUQOBD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

On 2020-02-03 16:44, Antoine Pitrou wrote:

On Mon, 3 Feb 2020 13:18:46 +0100
Petr Viktorin  wrote:


I agree with the sentiment that gradual deprecations are more easily
managed, this statement about Python 3.0 is not true. The unicode
transition was never thought to be small, and that's *why* 3.0 was such
a big change.


Alright, "very small" is an overstatement. But it did seem much smaller
than it turned out to be.
https://docs.python.org/3.0/whatsnew/3.0.html lists it as the last of
the big breaking changes, while most of the porting efforts were spent
on it.


I don't think the order in this page has any relationship to the
difficulty of each change.  I'm not sure there was any particular
reason to order them in this way, but it seems to me that the easier
to understand changes were put first.

AFAIR, we were all acutely aware that the text model overhaul was going
to be the hardest change for many users (especially those who have
never encountered non-ASCII input). Most other changes in Python 3 have
a predetermined context-free repair, while migrating to the new text
model requires *thinking* about the context in which each Python 2
bytestring is used.  It forces people to think about the problem
they're solving in ways many of them didn't think of it before.


I stand corrected. Thank you!
___
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/U327ZCIYDQ2QVSP2E7V3O4WGIA275GSS/
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]

Ethan Furman wrote:
> On 2020-01-23 07:20, Victor Stinner wrote:
> > Python 3.9 introduces many small incompatible changes
> > which broke tons
> > On 2020-01-31 19:47, Mike Miller wrote:
> > There's a well-known and established way of signaling
> > breaking changes in software platforms—it is to increment the major version 
> > number.
> > Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't 
> > it make more
> > sense to do it in a Python 4.0 instead?  Well, either of these strategies 
> > sound logical to
> > me:
> > 
> > Python 4.0 with removal of all of the Python 3-era deprecations
> > Continuing Python 3.1X with no breaks
> > 
> > In other words, we should keep compatibility, or not.  In any case, from 
> > the looks of
> > it these will be tiny breaks compared to the Unicode transition.
> > Ethan Furman wrote:
> > I've gotta say, I like that plan.  Instead of going
> > to x.10, go to x+1.0.  Every ten years we bump the major version and get 
> > rid of all the
> > deprecations.
> > Petr Viktorin wrote:
> > I don't. I hope the 10-year (and counting) transition
> > from Python 2 to Python 3 will not become a tradition.
> > I'd rather iterate on making removals less drastic (e.g. by making the 
> > DeprecationWarnings
> > more visible). Iterate with a feedback loop, rather than do a one-time 
> > change and hope
> > that everything goes well.
> > As a user I would much rather know that my 3.2 code worked in every version 
> > of
> 3.x, and not have to make changes in 3.5 and 3.7 and 3.11.  Talk about death 
> by paper
> cuts!  I'd either be stuck updating already working code to get the benefits 
> of the latest
> Python 3, or having multiple versions of Python 3 on my system.  Both options 
> are
> galling.
> Having the latest Python 2, the latest Python 3, and the latest Python 4 is 
> much more
> palatable.

Until you're being asked to maintain all of that for a decade. We paid a major 
price keeping Python 2 alive for over a decade. Now I'm not saying it wasn't 
the right thing to do considering what we changed, but for the stuff we are 
talking about removing it doesn't require a massive rewrite on the behalf of 
users. And we know from experience anything that is left in will get used no 
matter how loudly we try to broadcast that fact (and we know people still do 
not have a habit of running their code with warnings turned on).

I think people also forget that prior to worrying about maintaining 
backwards-compatibility with Python 2 we deprecated for a release and then we 
removed (so an 18 month deprecation period). Python survived, users survived, 
and we all had more time for other things than trying to keep deprecated stuff 
from completely rotting out (look at inspect and trying to wedge keyword-only 
arguments into argspec() and friends as to prices paid to keeping stuff we 
would have shifted users off of as having a cost). And I know some people think 
that if we flat-out say we won't touch deprecated code that it should be 
enough, but even triaging issues for deprecated stuff as "won't fix" is still 
not free.
___
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/352ZQCOMN4YN7HHS5U2UK2B353M3CBCP/
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 2020-01-23 07:20, Victor Stinner wrote:

Python 3.9 introduces many small incompatible changes which broke tons


On 2020-01-31 19:47, Mike Miller wrote:

There's a well-known and established way of signaling breaking changes in 
software platforms—it is to increment the major version number.

Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it 
make more sense to do it in a Python 4.0 instead?  Well, either of these 
strategies sound logical to me:

- Python 4.0 with removal of all of the Python 3-era deprecations
- Continuing Python 3.1X with no breaks

In other words, we should keep compatibility, or not.  In any case, from the 
looks of it these will be tiny breaks compared to the Unicode transition.


Ethan Furman wrote:
I've gotta say, I like that plan.  Instead of going to x.10, go to x+1.0.  Every ten years we bump the major version and get rid of all the deprecations. 


Petr Viktorin wrote:

I don't. I hope the 10-year (and counting) transition from Python 2 to Python 3 
will not become a tradition.
I'd rather iterate on making removals less drastic (e.g. by making the 
DeprecationWarnings more visible). Iterate with a feedback loop, rather than do 
a one-time change and hope that everything goes well.


As a user I would much rather know that my 3.2 code worked in every version of 
3.x, and not have to make changes in 3.5 and 3.7 and 3.11.  Talk about death by 
paper cuts!  I'd either be stuck updating already working code to get the 
benefits of the latest Python 3, or having multiple versions of Python 3 on my 
system.  Both options are galling.

Having the latest Python 2, the latest Python 3, and the latest Python 4 is 
much more palatable.

--
~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/HMYYAX6NCAT2MT5E32QXBMRJ2JH7JSNU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mike Miller]

On 2020-02-03 01:50, Petr Viktorin wrote:
When the changes are rolled out gradually across minor releases, those that 
cause unforeseen trouble in real-world code can be identified in the 
alphas/betas, and rethought/reverted if necessary.



To be clear, my suggestion was to maintain gradual deprecations and warnings, 
but have a single removal event at the start of a new version major number.  So 
there will be many years of betas and releases to haggle over.


Also, I believe it is possible to separate the "mechanically fixable" breaks 
from larger changes in fundamentals.  Few folks are willing to entertain or 
stomach the latter at this point in the lifecycle of Python.  If one happens to 
occur, scheduling it for X.4 instead of X+1.0 doesn't help much, and may serve 
to obscure it.


In some sense, distributing the breaks avoids potential/temporary bad press at 
the cost of easy planning.  However, it feels like a very regular, easy to 
understand process should trump that in the long run.


As a refinement to the idea above, perhaps a sub rule could be added:

  - No deprecations should appear in a X.9 release to give folks time
to prepare.

-Mike
___
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/A7DWXEXHIBQ24ZOMTJ55NYCWGFOHRPMS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

On Mon, 3 Feb 2020 13:18:46 +0100
Petr Viktorin  wrote:
> > 
> > I agree with the sentiment that gradual deprecations are more easily 
> > managed, this statement about Python 3.0 is not true. The unicode 
> > transition was never thought to be small, and that's *why* 3.0 was such 
> > a big change.  
> 
> Alright, "very small" is an overstatement. But it did seem much smaller 
> than it turned out to be.
> https://docs.python.org/3.0/whatsnew/3.0.html lists it as the last of 
> the big breaking changes, while most of the porting efforts were spent 
> on it.

I don't think the order in this page has any relationship to the
difficulty of each change.  I'm not sure there was any particular
reason to order them in this way, but it seems to me that the easier
to understand changes were put first.

AFAIR, we were all acutely aware that the text model overhaul was going
to be the hardest change for many users (especially those who have
never encountered non-ASCII input). Most other changes in Python 3 have
a predetermined context-free repair, while migrating to the new text
model requires *thinking* about the context in which each Python 2
bytestring is used.  It forces people to think about the problem
they're solving in ways many of them didn't think of it before.

Regards

Antoine.

___
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/HFGK6EFTOX7RIWFQE3B2AZ5PZ37SO6SB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

On 2020-02-03 12:55, Thomas Wouters wrote:



On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin > wrote:


On 2020-01-31 19:47, Mike Miller wrote:
 >
 > On 2020-01-23 07:20, Victor Stinner wrote:
 >  > Python 3.9 introduces many small incompatible changes which
broke tons
 >
 >
 > There's a well-known and established way of signaling breaking
changes
 > in software platforms—it is to increment the major version number.
 >
 > Rather than debating the merits of breaking code on 3.9 or 3.10,
 > wouldn't it make more sense to do it in a Python 4.0 instead?  Well,
 > either of these strategies sound logical to me:
 >
 > - Python 4.0 with removal of all of the Python 3-era deprecations
 > - Continuing Python 3.1X with no breaks
 >
 > In other words, we should keep compatibility, or not.  In any
case, from
 > the looks of it these will be tiny breaks compared to the Unicode
 > transition.

The Unicode transition also looked very small back when 3.0 was planned.
It only takes one such not-so-little thing to make a big breaking
release like 3.0. And even if all the changes were little, I wouldn't
want to inflict 10 years of papercuts at once.


I agree with the sentiment that gradual deprecations are more easily 
managed, this statement about Python 3.0 is not true. The unicode 
transition was never thought to be small, and that's *why* 3.0 was such 
a big change.


Alright, "very small" is an overstatement. But it did seem much smaller 
than it turned out to be.
https://docs.python.org/3.0/whatsnew/3.0.html lists it as the last of 
the big breaking changes, while most of the porting efforts were spent 
on it.



We knew it was going to break everything, so we took the 
opportunity to break more things, like the behaviour of indexing 
bytestrings. (Bytestrings were even going to be *mutable* for a while.) 
I think we can all agree that it was a mistake, and that's certainly 
something we don't want to repeat: even if we defer actual removal of 
features for a x.0.0 release, it must not become carte blanche for 
breaking things. >


When the changes are rolled out gradually across minor releases, those
that cause unforeseen trouble in real-world code can be identified in
the alphas/betas, and rethought/reverted if necessary.


That's also the case if things are (loudly) deprecated *but not removed* 
until a x.0.0 release. The replacement would already be in use for years 
before the old way would go away.


I fear that this is only so if no unexpected issues come up.
If we do a loud deprecation, how can we be sure we did it right?





Ethan Furman wrote:
 > I've gotta say, I like that plan.  Instead of going to x.10, go
to x+1.0.  Every ten years we bump the major version and get rid of
all the deprecations.

I don't. I hope the 10-year (and counting) transition from Python 2 to
Python 3 will not become a tradition.
I'd rather iterate on making removals less drastic (e.g. by making the
DeprecationWarnings more visible). Iterate with a feedback loop, rather
than do a one-time change and hope that everything goes well.

___
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/X5RBXEEB5BFPXGGGT2MTG4KZL3OBXQFD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Wouters]

On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin  wrote:

> On 2020-01-31 19:47, Mike Miller wrote:
> >
> > On 2020-01-23 07:20, Victor Stinner wrote:
> >  > Python 3.9 introduces many small incompatible changes which broke tons
> >
> >
> > There's a well-known and established way of signaling breaking changes
> > in software platforms—it is to increment the major version number.
> >
> > Rather than debating the merits of breaking code on 3.9 or 3.10,
> > wouldn't it make more sense to do it in a Python 4.0 instead?  Well,
> > either of these strategies sound logical to me:
> >
> > - Python 4.0 with removal of all of the Python 3-era deprecations
> > - Continuing Python 3.1X with no breaks
> >
> > In other words, we should keep compatibility, or not.  In any case, from
> > the looks of it these will be tiny breaks compared to the Unicode
> > transition.
>
> The Unicode transition also looked very small back when 3.0 was planned.
> It only takes one such not-so-little thing to make a big breaking
> release like 3.0. And even if all the changes were little, I wouldn't
> want to inflict 10 years of papercuts at once.
>

I agree with the sentiment that gradual deprecations are more easily
managed, this statement about Python 3.0 is not true. The unicode
transition was never thought to be small, and that's *why* 3.0 was such a
big change. We knew it was going to break everything, so we took the
opportunity to break more things, like the behaviour of indexing
bytestrings. (Bytestrings were even going to be *mutable* for a while.) I
think we can all agree that it was a mistake, and that's certainly
something we don't want to repeat: even if we defer actual removal of
features for a x.0.0 release, it must not become carte blanche for breaking
things.


>
> When the changes are rolled out gradually across minor releases, those
> that cause unforeseen trouble in real-world code can be identified in
> the alphas/betas, and rethought/reverted if necessary.
>

That's also the case if things are (loudly) deprecated *but not removed*
until a x.0.0 release. The replacement would already be in use for years
before the old way would go away.


>
>
> Ethan Furman wrote:
> > I've gotta say, I like that plan.  Instead of going to x.10, go to
> x+1.0.  Every ten years we bump the major version and get rid of all the
> deprecations.
>
> I don't. I hope the 10-year (and counting) transition from Python 2 to
> Python 3 will not become a tradition.
> I'd rather iterate on making removals less drastic (e.g. by making the
> DeprecationWarnings more visible). Iterate with a feedback loop, rather
> than do a one-time change and hope that everything goes well.
> ___
> 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/CHMOFONIBAACIW5A5SNHLTV6A5BEQXYT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/2R5CKAZICLAGNENAEBN6Z4ZNZRLM7YGW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

On 2020-01-31 19:47, Mike Miller wrote:


On 2020-01-23 07:20, Victor Stinner wrote:
 > Python 3.9 introduces many small incompatible changes which broke tons


There's a well-known and established way of signaling breaking changes 
in software platforms—it is to increment the major version number.


Rather than debating the merits of breaking code on 3.9 or 3.10, 
wouldn't it make more sense to do it in a Python 4.0 instead?  Well, 
either of these strategies sound logical to me:


- Python 4.0 with removal of all of the Python 3-era deprecations
- Continuing Python 3.1X with no breaks

In other words, we should keep compatibility, or not.  In any case, from 
the looks of it these will be tiny breaks compared to the Unicode 
transition.


The Unicode transition also looked very small back when 3.0 was planned.
It only takes one such not-so-little thing to make a big breaking 
release like 3.0. And even if all the changes were little, I wouldn't 
want to inflict 10 years of papercuts at once.


When the changes are rolled out gradually across minor releases, those 
that cause unforeseen trouble in real-world code can be identified in 
the alphas/betas, and rethought/reverted if necessary.



Ethan Furman wrote:
I've gotta say, I like that plan.  Instead of going to x.10, go to x+1.0.  Every ten years we bump the major version and get rid of all the deprecations. 


I don't. I hope the 10-year (and counting) transition from Python 2 to 
Python 3 will not become a tradition.
I'd rather iterate on making removals less drastic (e.g. by making the 
DeprecationWarnings more visible). Iterate with a feedback loop, rather 
than do a one-time change and hope that everything goes well.

___
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/CHMOFONIBAACIW5A5SNHLTV6A5BEQXYT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Raymond Hettinger]

> 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

+1 from me.  We don't gain anything by removing these in 3.9 instead of 3.10, 
so it is perfectly reasonable to ease the burden on users by deferring them for 
another release.


Raymond
___
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/52V6RP2WBC43OWTLBICS77MD3IGSV5CI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2020-01-31 19:58, Ethan Furman wrote:

On 01/31/2020 10:47 AM, Mike Miller wrote:

On 2020-01-23 07:20, Victor Stinner wrote:



Python 3.9 introduces many small incompatible changes which broke tons


There's a well-known and established way of signaling breaking changes in 
software platforms—it is to increment the major version number.

Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it 
make more sense to do it in a Python 4.0 instead?


I've gotta say, I like that plan.  Instead of going to x.10, go to x+1.0.  
Every ten years we bump the major version and get rid of all the deprecations.


It has a certain appeal for me too.
___
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/Q24LBBZ4P2PAUBU5B2K7HNXP3HJXFBEP/
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/31/2020 10:47 AM, Mike Miller wrote:

On 2020-01-23 07:20, Victor Stinner wrote:



Python 3.9 introduces many small incompatible changes which broke tons


There's a well-known and established way of signaling breaking changes in 
software platforms—it is to increment the major version number.

Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it 
make more sense to do it in a Python 4.0 instead?


I've gotta say, I like that plan.  Instead of going to x.10, go to x+1.0.  
Every ten years we bump the major version and get rid of all the deprecations.

--
~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/FBRKF3UKABFHEQYSFJSM6ED2QQSBK6DC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mike Miller]

On 2020-01-23 07:20, Victor Stinner wrote:
> Python 3.9 introduces many small incompatible changes which broke tons


There's a well-known and established way of signaling breaking changes in 
software platforms—it is to increment the major version number.


Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it 
make more sense to do it in a Python 4.0 instead?  Well, either of these 
strategies sound logical to me:


- Python 4.0 with removal of all of the Python 3-era deprecations
- Continuing Python 3.1X with no breaks

In other words, we should keep compatibility, or not.  In any case, from the 
looks of it these will be tiny breaks compared to the Unicode transition.


Cheers,
-Mike
___
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/OUHSUXWDWQ2TL7ZESB5WODLNHKMBZHYH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Philipp A.]

I think this particular mess was caused by the hiding of
“DeprecationWarning”s by default: If you don’t see any warnings cropping up
in your production code, you don’t know you have to fix something.

Some languages handle it like this:

   1. Silent deprecation warning (deprecated in docs and/or hidden like in
   Python, the most eagle-eyed maintainers will see it and fix it)
   2. Visible deprecation warning (people start seeing it and bug you in
   issues)
   3. Hide things behind a flag: You’ll have breakage but you get a grace
   perior by enabling some scary looking environment variable or so (nobody
   can deny that things are getting serious)
   4. Removal

Going from 1 to 4 is of course pretty harsh, and this is what we’re doing.

I propose that at least in the future, we have a schedule for every single
deprecation to go to a gradual process like above.

Best, Phil

Am Fr., 31. Jan. 2020 um 05:21 Uhr schrieb Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:

> Dima Tisnek writes:
>
>  > I thought that collections compatibility was kept up to 3.8
>  > specifically because py2 was alive.
>  > No that that requirement is gone, so should the shim, right?
>
> Python 2 is still very much alive (even in a Python 3 venv :-þ):
>
> (analysis.venv) 01 16:56$ /usr/bin/python
> Python 2.7.10 (default, Feb 22 2019, 21:55:15)
> [GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ^D
>
> We have stopped supporting Python 2 in the sense that we are no longer
> going to release source updates to Python 2.  That doesn't necessarily
> mean we don't consider the needs of users who continue to depend on
> Python 2 for one reason or another, excellent or totally (in our
> oh-so-ever-'umble opinion) mistaken though that reason may be.
>
>  > Ofc., my assumption could be just wrong...
>
> It might be, it might not be, it might be situation-dependent (ie,
> decisions should be made case by case on a cost to Python core
> developers versus benefits to Python 2 users and those who support
> them in their libraries etc basis).
>
> I think it would certainly be reasonable to make the decision that
> we're going to go full speed ahead with Python 3 and start stripping
> out Python 2-only features in the stdlib code.  I don't support that,
> but I'm not a core developer, so that's a +1.0e-17 for keeping the
> code.  I get the feeling that Guido is also not in favor of a
> Procrustean[1] approach to Python 2 support in the Python 3 stdlib,
> but I could be wrong.  Since he's not BDFL, that's merely indicative,
> but IMO it's a pretty strong indicator.
>
> What would really distress me however, is if we forget that we're not
> supporting *code*, we're supporting *users* by creating and
> maintaining code.  Of course we can choose that user base, and may
> have to make painful decisions.  But this community is about people
> supporting people, just like any community.
>
> Footnotes:
> [1]  Look up "Procrustes" in Wikipedia.  It's not a story to tell in
> this family setting. ;-)
> ___
> 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/WX4LA55VR35LEAM46WWMQHS2T5DZOZII/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/N5XWYZJEZRSMLG43BAL65YGLXDSVKS6C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

Dima Tisnek writes:

 > I thought that collections compatibility was kept up to 3.8
 > specifically because py2 was alive.
 > No that that requirement is gone, so should the shim, right?

Python 2 is still very much alive (even in a Python 3 venv :-þ):

(analysis.venv) 01 16:56$ /usr/bin/python
Python 2.7.10 (default, Feb 22 2019, 21:55:15) 
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

We have stopped supporting Python 2 in the sense that we are no longer
going to release source updates to Python 2.  That doesn't necessarily
mean we don't consider the needs of users who continue to depend on
Python 2 for one reason or another, excellent or totally (in our
oh-so-ever-'umble opinion) mistaken though that reason may be.

 > Ofc., my assumption could be just wrong...

It might be, it might not be, it might be situation-dependent (ie,
decisions should be made case by case on a cost to Python core
developers versus benefits to Python 2 users and those who support
them in their libraries etc basis).

I think it would certainly be reasonable to make the decision that
we're going to go full speed ahead with Python 3 and start stripping
out Python 2-only features in the stdlib code.  I don't support that,
but I'm not a core developer, so that's a +1.0e-17 for keeping the
code.  I get the feeling that Guido is also not in favor of a
Procrustean[1] approach to Python 2 support in the Python 3 stdlib,
but I could be wrong.  Since he's not BDFL, that's merely indicative,
but IMO it's a pretty strong indicator.

What would really distress me however, is if we forget that we're not
supporting *code*, we're supporting *users* by creating and
maintaining code.  Of course we can choose that user base, and may
have to make painful decisions.  But this community is about people
supporting people, just like any community.

Footnotes: 
[1]  Look up "Procrustes" in Wikipedia.  It's not a story to tell in
this family setting. ;-)
___
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/WX4LA55VR35LEAM46WWMQHS2T5DZOZII/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

On 2020-01-30 07:12, Dima Tisnek wrote:

On Fri, 24 Jan 2020 at 00:27, Victor Stinner  wrote:


Miro and me consider that Python 3.9 is pushing too much pressure on
projects maintainers to either abandon Python 2.7 right now...


Let's not conflate py2 EOL with what-should-go-into-py39.


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


Please provide a better summary.
I've looked at first 3 failed packages, and:

* `afflib` only has these error lines:
```
warning: extra tokens at the end of %endif directive in line 186:
%endif # with_python2
warning: extra tokens at the end of %endif directive in line 195:
%endif # with_python3
```
I don't know if that's why the build is considered failed, but that
issue seems to be on the build script side.


Those are just warnings; ignore them.
afflib didn't build because it's missing a dependency 
(libtermcap-devel). It wasn't counted in the ones with Python-related 
problems.



* `python-django-post_office` doesn't have any stderr output or other
indication why the build failed.


Same situation (this time missing python3-django-jsonfield).


* `ansible-lint` same, does this package even use Python?


And that one is missing python3-passlib, which fails several tests; one 
of them being ImportError: cannot import name 'MutableMapping' from 
'collections'.




https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON39
- Has open Python 3.9 bug reports for Fedora packages. Some problems


I feel it's still early days for py39 and well-maintained packages are
expected to catch up.
> I, for one, just started testing our crud against py39a3 yesterday,
and yes some tools and libraries are broken, so I've opened issues and
might post a PR, depending.

I get the gist from your email that you are (or fedora folks are)
doing the same.


Definitely! That's exactly what we're doing: helping the well-maintained 
packages catch up, via bug reports and pull requests as capacity allows.


And now we're reporting back that the most common change these packages 
have to make is the collections.abc removal, and that since many 
projects are planning to drop py2 compat later in 2020, the pull request 
we need to send is ugly -- and it could be much nicer one-liner in 2021 
if the collections.abc removal was postponed.



So, what's the rationale to change py39 change set?


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




I thought that collections compatibility was kept up to 3.8
specifically because py2 was alive.
No that that requirement is gone, so should the shim, right?
Ofc., my assumption could be just wrong...


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.


I see some semi-abandoned projects, as well as actively maintained
projects not addressing DeprecationWarnings.
I don't know if some projects just need a harder push (will break, not
just deprecated).
Either way, my gut tells me, if py39 was changed and became very
compatible, we'd see the same discussion in 2021.


Not really. For projects that want to stay be py2/py3-compatible for the 
long term, the long "try/except ImportError" dance makes sense.



* 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


my 2c: all of these are truly minor.

I have a feeling that the discussion is just wrong altogether.
It should not be "let's remove" or "let's keep".
It should not be "let's keep x but not y".

It should be something along the lines of:
* here's a great tool that fedora has that shows which libraries need
changes (your links + better output)
* here's a build server, where existing packages (maybe not fedora)
can be tested and built on py39, new ABI, etc.
* [optional] it would be awesome if anyone could submit their repo url
and the server would automatically build wheels for all arch,abi and
publish to pypi
* let's notify package maintainers (presumably done?) and if that
doesn't yield the desired result,
* let's organise the open-source community (via fame or bounties) and
fix (or fork) those that are important (common [transitive] deps to
many fedora packages)


Yes! Except a few details, that's just what I'd like to do in the long 
term. Do you want to help?

___
Python-Dev mailing list -- 

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

[Dima Tisnek]

On Fri, 24 Jan 2020 at 00:27, Victor Stinner  wrote:

> Miro and me consider that Python 3.9 is pushing too much pressure on
> projects maintainers to either abandon Python 2.7 right now...

Let's not conflate py2 EOL with what-should-go-into-py39.

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

Please provide a better summary.
I've looked at first 3 failed packages, and:

* `afflib` only has these error lines:
```
warning: extra tokens at the end of %endif directive in line 186:
%endif # with_python2
warning: extra tokens at the end of %endif directive in line 195:
%endif # with_python3
```
I don't know if that's why the build is considered failed, but that
issue seems to be on the build script side.
* `python-django-post_office` doesn't have any stderr output or other
indication why the build failed.
* `ansible-lint` same, does this package even use Python?

> https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON39
> - Has open Python 3.9 bug reports for Fedora packages. Some problems

I feel it's still early days for py39 and well-maintained packages are
expected to catch up.

I, for one, just started testing our crud against py39a3 yesterday,
and yes some tools and libraries are broken, so I've opened issues and
might post a PR, depending.

I get the gist from your email that you are (or fedora folks are)
doing the same.

So, what's the rationale to change py39 change set?

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

I thought that collections compatibility was kept up to 3.8
specifically because py2 was alive.
No that that requirement is gone, so should the shim, right?
Ofc., my assumption could be just wrong...

> 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.

I see some semi-abandoned projects, as well as actively maintained
projects not addressing DeprecationWarnings.
I don't know if some projects just need a harder push (will break, not
just deprecated).
Either way, my gut tells me, if py39 was changed and became very
compatible, we'd see the same discussion in 2021.

> * 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

my 2c: all of these are truly minor.

I have a feeling that the discussion is just wrong altogether.
It should not be "let's remove" or "let's keep".
It should not be "let's keep x but not y".

It should be something along the lines of:
* here's a great tool that fedora has that shows which libraries need
changes (your links + better output)
* here's a build server, where existing packages (maybe not fedora)
can be tested and built on py39, new ABI, etc.
* [optional] it would be awesome if anyone could submit their repo url
and the server would automatically build wheels for all arch,abi and
publish to pypi
* let's notify package maintainers (presumably done?) and if that
doesn't yield the desired result,
* let's organise the open-source community (via fame or bounties) and
fix (or fork) those that are important (common [transitive] deps to
many fedora packages)

Cheers,
d.
___
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/AGR66AM2FXBG7URXC6KZDOY3HLSKMDC4/
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]

Matthias Bussonnier wrote:
> Is it possible to change some of those deprecation from Warn-by-default (but 
> can add a
> warning filter to make them error) to error-by-default (but can add a filter 
> to make them
> only warnings).

Yes, although it would be a change to how Python functions. Basically we would 
need a default warnings filter with either a very specific regex or a new 
warnings subclass which made silencing warning more opt-out instead of opt-in.

But considering the vast amount of discussions we have had about when to even 
turn on warnings I don't know if this idea will get traction.

-Brett

> That way it is easy to fix large projects (even w/o modifying the source) in 
> only a
> couple of lines of codes; and they buy themselves a year or so and remove in 
> 3.10.
> That way you have a more gradual transition; and a clear signal to project 
> with a last
> chance to fix issues.
> And that way can't complained they did not know as they have to opt-in.
___
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/NGNTVPPHKUKWWZ3MRSRPBMBDF322F4A3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Matthias Bussonnier]

Is it possible to change some of those deprecation from Warn-by-default (but 
can add a warning filter to make them error) to error-by-default (but can add a 
filter to make them only warnings). 

That way it is easy to fix large projects (even w/o modifying the source) in 
only a couple of lines of codes; and they buy themselves a year or so and 
remove in 3.10. 

That way you have a more gradual transition; and a clear signal to project with 
a last chance to fix issues.
And that way can't complained they did not know as they have to opt-in.
___
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/7BMWSTC4WUXOZ3MKQKSXWKEX6QLYHNU2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Matthias Bussonnier]

Is it possible to change some of those deprecation from Warn-by-default (but 
can add a warning filter to make them error) to error-by-default (but can add a 
filter to make them only warnings). 

That way it is easy to fix large projects (even w/o modifying the source) in 
only a couple of lines of codes; and they buy themselves a year or so and 
remove in 3.10. 

That way you have a more gradual transition; and a clear signal to project with 
a last chance to fix issues.
And that way can't complained they did not know as they have to opt-in.
___
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/CMO7H5A4IHXRR52SDOBSPE25C7UW6A7T/
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 27, 2020, at 13:56, Barry Scott  wrote:
> 
> Isn't there going to be a final Python 2.7 release in April 2020?

Yes, but I’ve been calling it a “celebratory release”.  We’re gonna party at 
Pycon like it’s 2000.

-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/FHK5X2XNPXZC2CSZ424XBOZTMAEUJ2IN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Terry Reedy]

On 1/27/2020 4:56 PM, Barry Scott wrote:

On 24 Jan 2020, at 08:40, Victor Stinner  wrote:
The change is that Python 2.7 is no longer supported (since 2020-01-01).

Isn't there going to be a final Python 2.7 release in April 2020?


Normal patching has stopped, much as if the final .rc1 release candidate 
had been issued.  I believe Benjamin want to hit the final release 
button live at PyCon.


--
Terry Jan Reedy
___
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/PKQ3LXXCQGXGQ2QHL5PMLQSWJCVD3Z52/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Miro Hrončok]

On 24. 01. 20 22:54, Serhiy Storchaka wrote:

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 for a very long time. On 
other side, most time it was silent deprecation, and the removal will affect too 
much projects. I agree with deferring this removal.


Some data points:

This has so far affected ~65 from ~200 projects that we found fail to build in 
Fedora w/3.9.



 > * Remove "U" mode of open(): having to use io.open() just for Python 2
 > makes the code uglier


~10


* Removed tostring/fromstring methods in array.array and base64 modules


~10


* Removed fractions.gcd() function (which is similar to math.gcd())


0


* Removed old plistlib API: 2.7 doesn't have the new API


2

--
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/LGGI42UEQMJVNW2ZHEP473Z7ZQ5BDBPL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Miro Hrončok]

On 24. 01. 20 16:22, 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 2.7. And many library authors aren't willing to do that yet. 
Will they be willing to in another year? I can't say.


The concern is not that they don't want to drop 2.7 support, but that is is a 
nontrivail task to actaually do and we cannot expect them to do it within the 
first couple weeks of 2020. While at the same time, we want them to support 
3.9 since the early development versisons in order to eb able to detect 
regressions early in the dev cycle.


Ah. So in 3.8, they kept code that had deprecation warnings so that they could 
be compatible with 2.7. They'd like to now drop that code and be 3.9-only 
compatible, but they don't have enough time to do that because they couldn't 
start that work as long as they were supporting 2.7. Do I have that right?


Yes.

If so, I'd be okay with postponing the removal of the deprecated code until 
3.10. But I don't think we should postpone it if the driver is so that libraries 
can remain 2.7 compatible. That could go on forever. This postponement would be 
a one-time thing.


--
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/ZKVPNSAX5NPTWVOD6Y6FLBBLZWFIXUVN/
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]

See pyfound.blogspot.com/2019/12/python-2-sunset.html for the details.

January or April doesn't matter much for this thread, since Python
3.9.0 final is scheduled for October.

Victor

Le lun. 27 janv. 2020 à 23:13, Barry Scott  a écrit :
>
>
>
> > On 24 Jan 2020, at 08:40, Victor Stinner  wrote:
> >
> > The change is that Python 2.7 is no longer supported (since 2020-01-01).
> >
>
> Isn't there going to be a final Python 2.7 release in April 2020?
>
> I know that Twisted has moved its python 2 removal to match the
> April 2020 date. Other projects may have made the similar decisions.
>
> Barry
>
>
>
>
> > 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 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 from the standard library until Python 2.7 is
> >>> no longer supported as specified by PEP 373."
> >>>
> >>> The rule was used since Python 3.0 until Python 3.8, but it changed in
> >>> Python 3.9 which includes many incompatible changes for the first time
> >>> in the Python 3 major version.
> >>
> >> I'm sorry, I don't understand what 'changed'. Isn't that rule exactly
> >> WHY 3.9 is the removal point? Python 2.7 is no longer supported, and
> >> its final post-support release is scheduled earlier than 3.9's first
> >> beta and feature freeze. Doesn't that mean that PEP 4 is being
> >> followed precisely? What have I misunderstood?
> >>
> >> ChrisA
> >> ___
> >> 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/GCCLU2O2QJTGECQKUYEHD2KVD3IKJTLE/
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> >
> > --
> > 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/6YLZXTOJJ7XGISGRITJV7OAEOEKFYZS7/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
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/YIFL5OANIFXSSR7LHT2FCQZWNTFZWY26/
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 Scott]

> On 24 Jan 2020, at 08:40, Victor Stinner  wrote:
> 
> The change is that Python 2.7 is no longer supported (since 2020-01-01).
> 

Isn't there going to be a final Python 2.7 release in April 2020?

I know that Twisted has moved its python 2 removal to match the
April 2020 date. Other projects may have made the similar decisions.

Barry




> 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 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 from the standard library until Python 2.7 is
>>> no longer supported as specified by PEP 373."
>>> 
>>> The rule was used since Python 3.0 until Python 3.8, but it changed in
>>> Python 3.9 which includes many incompatible changes for the first time
>>> in the Python 3 major version.
>> 
>> I'm sorry, I don't understand what 'changed'. Isn't that rule exactly
>> WHY 3.9 is the removal point? Python 2.7 is no longer supported, and
>> its final post-support release is scheduled earlier than 3.9's first
>> beta and feature freeze. Doesn't that mean that PEP 4 is being
>> followed precisely? What have I misunderstood?
>> 
>> ChrisA
>> ___
>> 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/GCCLU2O2QJTGECQKUYEHD2KVD3IKJTLE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 
> -- 
> 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/6YLZXTOJJ7XGISGRITJV7OAEOEKFYZS7/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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/C65AAFHWSN46SI5NBF735MPF242NRSQC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steve Dower]

On 25Jan.2020 0348, Guido van Rossum wrote:
> 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 be
> so judgmental. We've broken enough code for a lifetime with the Python 2
> transition. Let's be *much* more conservative when we remove things from
> Python 3. Deprecation is fine, and we should look for other ways to
> handle the problem of unmaintained code. But we should not rush language
> or stdlib changes for this purpose.

I'd like to *strongly* agree with this sentiment.

Marking things as deprecated when we don't like them is a perfectly good
way to advise against their use (and give ourselves permission to let
bit-rot set in). But unless they are an actual maintenance burden, we
gain literally nothing by removing them, and actively hurt our
already-hurting users.

As much as we know that 3.x->3.y is a major version change, many of our
users don't think of them like that (in part because they come out so
often). The more we can keep things working between them, warts or not,
the better.

Cheers,
Steve
___
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/IYQNATVOQ5XVVMZPXTZMTS5JLRGAO2BV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 for a 
very long time. On other side, most time it was silent deprecation, and 
the removal will affect too much projects. I agree with deferring this 
removal.


> * Remove "U" mode of open(): having to use io.open() just for Python 2
> makes the code uglier

io.open() (don't confuse with codecs.open(), which was recommended in 
the past) has other advantages. Builtin open() has problems with threads 
in Python 2.



* Removed tostring/fromstring methods in array.array and base64 modules
* Removed fractions.gcd() function (which is similar to math.gcd())
* Removed old plistlib API: 2.7 doesn't have the new API


As for other changes, they look minor, and I think they affect not much 
code. In particular, plistlib is specific for macOS.

___
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/XI3TNNNXT5F66Y2WEZRQTDZX3L4NJJ2T/
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 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 
> and they realize that they now have to start caring about deprecation 
> warnings again. So I'm okay letting 3.9 be the release where we loudly 
> declare, "deprecation warnings matter again! Keep your code warnings-free 
> going forward as things will start being removed in 3.10".

Maybe we can put a strong statement at the What's New In Python 3.9 document?

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/5PTA432JSFSNRU3QAKXM727KDK6ZI7UX/
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 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 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/CUO7GQTOJHL3XXD64G6DM7UL7AXHFOWE/
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]

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 2.7. And many library 
> > authors aren't willing to do that yet. Will they be willing to in 
> > another year? I can't say.
> > The concern is not that they don't want to drop 2.7 support, but that 
> > is is a nontrivai task to actually do and we cannot expect them to 
> > do it within the first couple weeks of 2020. While at the same time, 
> > we want them to support 3.9 since the early development versisons in 
> > order to eb able to detect regressions early in the dev cycle.
> > Ah. So in 3.8, they kept code that had deprecation warnings so that they 
> could be compatible with 2.7. They'd like to now drop that code and be 
> 3.9-only compatible, but they don't have enough time to do that because 
> they couldn't start that work as long as they were supporting 2.7. Do I 
> have that right?
> If so, I'd be okay with postponing the removal of the deprecated code 
> until 3.10. But I don't think we should postpone it if the driver is so 
> that libraries can remain 2.7 compatible. That could go on forever. This 
> postponement would be a one-time thing.

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 
and they realize that they now have to start caring about deprecation warnings 
again. So I'm okay letting 3.9 be the release where we loudly declare, 
"deprecation warnings matter again! Keep your code warnings-free going forward 
as things will start being removed in 3.10".
___
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/ZLYXUBPHMRTAZFO3W6TPEUSOB7XNVW7H/
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]

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 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.

Ah, thanks! To put this in perspective, pytest had 631,008 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?

Sorry, North American phrase. It means you put the important part way down 
towards the bottom. Another North American phrase that might apply is "burying 
the lead".

Basically you put the interesting, important stuff so far down it was easy to 
overlook. :) My suggestion would have been to structure the email as "Fedora is 
seeing some transition problems for projects ATM. Reverting these 5 changes and 
postponing them to 3.10 would help a lot, and here is a bunch of detail about 
why we are making this proposal." IOW putting the list towards the top makes it 
easier to set expectations of what you're asking for while you try to justify 
the request, otherwise I could be reading most of that email as if you're 
suggesting we bring back the print statement or something. ;)

> 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/JGDXB6DAXT5TAFH2TJGV5VU456BZXPKP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 be so
judgmental. We've broken enough code for a lifetime with the Python 2
transition. Let's be *much* more conservative when we remove things from
Python 3. Deprecation is fine, and we should look for other ways to handle
the problem of unmaintained code. But we should not rush language or stdlib
changes for this purpose.

-- 
--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/6GO2CI55RJI5X3KJVVHCKOGLUNVCDI5L/
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/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 (2020-01-01).


Also I am not sure it is really worth it. For example, importing ABCs directly 
from collections was deprecated 8 years ago,
what would 1 extra year change?


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 willing to do that yet. 
Will they be willing to in another year? I can't say.


I'm not dropping support for 2.7 for the foreseeable future for my libraries, 
so an extra year won't help me at all (other than give me another 12 months to 
procrastinate).

--
~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/FF67UGONJUGVKYNBDKMDEE3YZX4UBXC3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 library authors aren't willing to do that yet.
> > Will they be willing to in another year? I can't say.
>
> The concern is not that they don't want to drop 2.7 support, but that is is a
> nontrivail task to actaually do and we cannot expect them to do it within the
> first couple weeks of 2020. While at the same time, we want them to support 
> 3.9
> since the early development versisons in order to eb able to detect 
> regressions
> early in the dev cycle.

But couldn't they have done that by adding the compatibility shims
Victor described. Sure, they are messy, and sure, it would be more
convenient not to have to. But the various dates have been known for
some time now. Unless you're saying that the change to a yearly
schedule for 3.9 has suddenly compressed timescales to an extent that
projects can't cope with.

So maybe there is a reason why people might legitimately have an issue
here. Having said that, I think that far more people will see this as
yet another delay before 2.7 dies, and treat it as one more reason to
do nothing. So I still have reservations.

I have already said that the 5 deprecations Victor described seem
minor enough that one release's delay is not a big deal. If that's
enough for the people hit by the shorter 3.9 cycle, then great. But it
should *not* set a precedent that we're willing to repeatedly have
this sort of discussion. It should be a one-off, and definitely not
set the scene for a series of "and can this one be added as well"
requests.

I assume it's obvious that 3.10 would be a hard deadline, as well.
There's no justification for deferring deprecations past then.

Paul

PS As a pip developer, I fully expect to be supporting Python 2.7 for
a while yet. So I'm not talking from a perspective of someone who has
happily dropped Python 2 support and doesn't understand the issues.
But I don't expect *Python* to maintain my compatibility for me, and I
don't see why others should, either. And yes, that does include these
5.
___
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/V5P5FSNA5QMP3P4VIFG3774JXE2PJ2P4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 willing to do that yet. Will they be willing to in 
another year? I can't say.


The concern is not that they don't want to drop 2.7 support, but that 
is is a nontrivail task to actaually do and we cannot expect them to 
do it within the first couple weeks of 2020. While at the same time, 
we want them to support 3.9 since the early development versisons in 
order to eb able to detect regressions early in the dev cycle.


Ah. So in 3.8, they kept code that had deprecation warnings so that they 
could be compatible with 2.7. They'd like to now drop that code and be 
3.9-only compatible, but they don't have enough time to do that because 
they couldn't start that work as long as they were supporting 2.7. Do I 
have that right?


If so, I'd be okay with postponing the removal of the deprecated code 
until 3.10. But I don't think we should postpone it if the driver is so 
that libraries can remain 2.7 compatible. That could go on forever. This 
postponement would be a one-time thing.


Eric

___
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/VPKPA5JW2G22LB7A4OWESIL6O25GSOIK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Miro Hrončok]

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 just happened a few weeks
ago (2020-01-01).


IMO creating this kind of "gray areas" in support and deprecation issues is bad.
What this will create is just more sources for arguing/debates. Once 
deprecation or EoL schedule is set,
it is best to align to it. Discussions about the schedules should happen when 
setting them, not when

the deadline is coming.

Also I am not sure it is really worth it. For example, importing ABCs directly 
from collections was deprecated 8 years ago,

what would 1 extra year change?

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 willing to do that yet. 
Will they be willing to in another year? I can't say.


The concern is not that they don't want to drop 2.7 support, but that is is a 
nontrivail task to actaually do and we cannot expect them to do it within the 
first couple weeks of 2020. While at the same time, we want them to support 3.9 
since the early development versisons in order to eb able to detect regressions 
early in the dev cycle.


--
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/RIEAHEAZZXHFRTUPZOC42OPMP6TSLZJE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 (2020-01-01).


IMO creating this kind of "gray areas" in support and deprecation 
issues is bad.
What this will create is just more sources for arguing/debates. Once 
deprecation or EoL schedule is set,
it is best to align to it. Discussions about the schedules should 
happen when setting them, not when

the deadline is coming.

Also I am not sure it is really worth it. For example, importing ABCs 
directly from collections was deprecated 8 years ago,

what would 1 extra year change?

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 
willing to do that yet. Will they be willing to in another year? I can't 
say.


Eric


___
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/DKZBXOYUPJCL3PUXWDJOJUEPG4WDYNF7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ivan Levkivskyi]

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 is
bad.
What this will create is just more sources for arguing/debates. Once
deprecation or EoL schedule is set,
it is best to align to it. Discussions about the schedules should happen
when setting them, not when
the deadline is coming.

Also I am not sure it is really worth it. For example, importing ABCs
directly from collections was deprecated 8 years ago,
what would 1 extra year change?

--
Ivan
___
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/YIBWOAXT5LGP3WM4T4DR5WJIVU7VVF7Z/
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]

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 (2020-01-01).

Big projects have more resources to schedule dropping Python 2
support, coordinated with other projects:
https://python3statement.org/

But for smaller projects with less resources, it's more complicated.
Many very popular Python modules are maintained by a single person
with limited resources. Even if we propose pull requests, it still
takes time to review it, prepare a new release, etc.

Victor

Le ven. 24 janv. 2020 à 09:42, Chris Angelico  a écrit :
> 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



-- 
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/LJTWEBG5NCLKKC4TY4I3JA2CYCMLUXO3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 newer Python versions is routine.
Anyone maintaining Python 2.7 compatibility should already be
painfully aware that we're deprecating things in 3.x and they have to
maintain compatibity code for that. We've been minimising the impact
for such people as much as we can for years. When *should* we stop
doing so, if not at the point where we finally declared 2.7
unsupported?

Having said that, the 5 specific changes noted seem relatively minor
and deferring them an extra release doesn't seem like a massive deal.
My objection is only if we try to extrapolate a general principle from
those specific examples.

Paul

P.S.

> I'm not sure of the meaning of "buried" here. What do you mean? We propose to 
> revert 5 changes:
[...]
> 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.

I agree with Brett, it was hard to understand your message. And I
think the problem was that you tried to discuss both the *specific*
proposal to delay 5 deprecations, and the *general* principle of when
we stop preserving 2.7 compatibility layers. These two are very
different questions and (as I say above) don't necessarily have the
same answer.

I think you should have posted *two* messages. The first very focused
on the 5 deprecations, and the second, following on, saying something
along the lines of "the previous message raises a broader question of
how long we should carry 2.7 compatibility code before removing it -
what do people think?". That would separate the general from the
specific, while not flooding the list with separate threads for each
deprecation (which I assume wasn't a serious suggestion on your part).
___
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/BLDYTQAHHIA6DLZZBQSW3E7WJVKLRP5W/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 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/HB6UQMP7FUKT6EAXZDTTCBNMGGJ7NWAC/
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]

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 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 from the standard library until Python 2.7 is
> > no longer supported as specified by PEP 373."
> >
> > The rule was used since Python 3.0 until Python 3.8, but it changed in
> > Python 3.9 which includes many incompatible changes for the first time
> > in the Python 3 major version.
>
> I'm sorry, I don't understand what 'changed'. Isn't that rule exactly
> WHY 3.9 is the removal point? Python 2.7 is no longer supported, and
> its final post-support release is scheduled earlier than 3.9's first
> beta and feature freeze. Doesn't that mean that PEP 4 is being
> followed precisely? What have I misunderstood?
>
> ChrisA
> ___
> 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/GCCLU2O2QJTGECQKUYEHD2KVD3IKJTLE/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
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/6YLZXTOJJ7XGISGRITJV7OAEOEKFYZS7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ivan Pozdeev via Python-Dev]

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
* 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


You had years to fix deprecation warnings in your code. And many projects did this long ago. If revert these removals in 3.9 because they 
break existing code we will have the same problem with removing them in 3.10, 13.11, etc.


I consider breaking unmaintained code is an additional benefit of removing deprecated features. For example pycrypto was unmaintained and 
insecure for 6 years, but has 4 million downloads per month. It will not work in 3.9 because of removing time.clock. Other example is 
nose, unmaintained for 5 years, and superseded by nose2.


AFAICS the justification for this proposition is the fact that the necessary fixes to existing code are much simpler if that code needs to 
support just 3.x-3.10 vs 2.7+3.x-3.10 .


In this light, with the breaking changes, we essentially tell the users: "abandon 
2.7 or do extra work".
Victor alleges that after a year, the option to abandon 2.7 and not do that 
extra work will be easier to choose.
So the dilemma is essentially how hard we push users to abandon 2.7 -- how much 
tax we incur on them for keeping its support.


___
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/DDVY3DG5NSFIW72EHXNFGH7J4ZXHY7HX/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Regards,
Ivan
___
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/BK2KCVRWCROMD72AEG6DUNZR2BJAQCG2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 enough breaking changes planned in 3.10. Even changing the 
minor version number to two-digit is a large breaking 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/ET3UXMU7BXGZT37D2AUJS5NRQRJNZ4W3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 from the standard library until Python 2.7 is
> no longer supported as specified by PEP 373."
>
> The rule was used since Python 3.0 until Python 3.8, but it changed in
> Python 3.9 which includes many incompatible changes for the first time
> in the Python 3 major version.

I'm sorry, I don't understand what 'changed'. Isn't that rule exactly
WHY 3.9 is the removal point? Python 2.7 is no longer supported, and
its final post-support release is scheduled earlier than 3.9's first
beta and feature freeze. Doesn't that mean that PEP 4 is being
followed precisely? What have I misunderstood?

ChrisA
___
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/GCCLU2O2QJTGECQKUYEHD2KVD3IKJTLE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 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


You had years to fix deprecation warnings in your code. And many 
projects did this long ago. If revert these removals in 3.9 because they 
break existing code we will have the same problem with removing them in 
3.10, 13.11, etc.


I consider breaking unmaintained code is an additional benefit of 
removing deprecated features. For example pycrypto was unmaintained and 
insecure for 6 years, but has 4 million downloads per month. It will not 
work in 3.9 because of removing time.clock. Other example is nose, 
unmaintained for 5 years, and superseded by nose2.

___
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/DDVY3DG5NSFIW72EHXNFGH7J4ZXHY7HX/
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 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
> Python 2.7, we ask them to support 3.9 from the same code base.

Let me give you an example. The python-ipmi project works on Python
2.7-3.8, but it is not longer compatible with Python 3.9 because
tostring/fromstring methods have been removed from array.array. IMO
this change is a good example to illustrate the issue:
https://github.com/kontron/python-ipmi/pull/73/files

I chose to add py3_array_tobytes() and py3_array_frombytes() functions
rather than adding "if _PY3: ... else: ...". Example:

- self.minor = int(data[1:2].tostring().decode('bcd+'))
+ self.minor = int(py3_array_tobytes(data[1:2]).decode('bcd+'))

This change reminds me when I added "Python 3" support to dozens of
Python projects. You can see in this PR that Python 3.9 currently
requires to modify 9 files in a small project. It is likely to be
worse in a larger project.

With Python 3.9, we cannot simply group all Python 3.x versions under
"Python 3" anymore. Currently, a code compatible with "Python 3" means
more likely compatible with "Python 3.5-3.8" ("Python 3.3-3.8" for the
most conservative projects?).

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 from the standard library until Python 2.7 is
no longer supported as specified by PEP 373."

The rule was used since Python 3.0 until Python 3.8, but it changed in
Python 3.9 which includes many incompatible changes for the first time
in the Python 3 major version.

Victor



>
>
> 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/



--
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/UAG4EXDRJAJFVQPHVEU5A5WULFSIYRSF/
Code of Conduct: http://python.org/psf/codeofconduct/

[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: 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: 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] 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/