This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients BTaskaya, carljm, eric.snow, gregory.p.smith, gvanrossum
Date 2020-04-24.22:55:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1587768935.34.0.495475369749.issue40360@roundup.psfhosted.org>
In-reply-to
Content
I think what we're doing with the documentation update is fine.  We can add a warning on stderr to the tool in 3.11.  But I don't expect people will be using the tool _from_ the latest CPython 3.x by then.

2to3 is already included with Python 2.7 and the only real use for it is for people who still have code they maintain on 2.7 so they've got a copy already.  There is no value in running a 2to3 shipped with Python 3 vs the latest 2.7.  Meaningful updates to it were already back ported to 2.7 over time as it was intentionally exempt from feature freeze.

We should have sorted out a PyPI home for lib2to3 by 3.11 time and can also create a PyPI package for the 2to3 tool itself at that point.

I _think_ there is support for running 2to3 on sources at package install time from setup.py?  But I don't expect anything actually maintained and widely used to require that by the time this deprecation lands.  If it does, that becomes a plumbing issue within package tools to know that requiring 2to3 at either build or install time adds an implicit tool dependency on the new pypi package to get it.

Maybe I'm just in a good mood about all of this, but none of this seems worrisome.
History
Date User Action Args
2020-04-24 22:55:35gregory.p.smithsetrecipients: + gregory.p.smith, gvanrossum, carljm, eric.snow, BTaskaya
2020-04-24 22:55:35gregory.p.smithsetmessageid: <1587768935.34.0.495475369749.issue40360@roundup.psfhosted.org>
2020-04-24 22:55:35gregory.p.smithlinkissue40360 messages
2020-04-24 22:55:35gregory.p.smithcreate