Actually, you can't remove any module in the stdlib that exists in both Python 2.7 and 3.5 until after Python 2.7 is no longer supported: https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5 .
On Thu, 28 Sep 2017 at 23:31 Nick Coghlan <ncogh...@gmail.com> wrote: > On 29 September 2017 at 07:42, Matthias Klose <d...@ubuntu.com> wrote: > > On 27.09.2017 11:37, Nick Coghlan wrote: > >> On 27 September 2017 at 12:30, xoviat <xov...@gmail.com> wrote: > >>>> In short, I think your proposal is a good one, but how can we allocate > >>>> manpower? > >>> > >>> (issue31595 on bugs.python.org) > >>> > >>> So what do others think of this? My sense of things is that people are > open > >>> to the idea, but there isn't a plan to make it happen. > >> > >> As long as Jason is amenable to the idea on the setuptools side, and > >> pip's trick of injecting setuptools into a process to change the > >> behaviour of distutils imports continues to work, then this seems like > >> a reasonable idea to me. > >> > >> There will still be folks that want to patch distutils itself, but I > >> don't see that as being substantially different from folks still > >> patching the standard library Tcl/Tk bindings, even though there are a > >> number of popular non-stdlib GUI toolkits. > > > > In this case, we should deprecate distutils in python3.7 and remove it > in 3.8. > > Aye, that seems reasonable to me as well (especially if 3.7+ also > offers an "ensuresetuptools" module), and, looking at the recent(-ish) > commit history at > https://github.com/python/cpython/commits/master/Lib/distutils, I'd > suggest we ask Steve Dower if he'd be willing to be BDFL-Delegate for > the related PEP. > > This is one of those changes where the longer term process improvement > benefits are already reasonably clear to the folks involved in > maintaining the software (i.e. we think it will provide a better end > user experience overall if distutils switches to being updated and > versioned based on the setuptools release cycle rather than the > reference interpreter & standard library one), so the main thing the > PEP process will need to ensure is that we're providing a sufficiently > non-disruptive transition plan for getting from the current state to > the more desirable state. > > Between Steve ("Don't break Windows"), you ("Don't break Debian (et > al)"), me ("Don't break Fedora (et al)"), Donald ("Don't break pip"), > and Jason ("Don't break setuptools"/"Don't lumber setuptools with an > unreasonable ongoing maintenance burden"), along with everyone else on > distutils-sig, python-ideas, and python-dev, I think we'll be able to > make a reasonable assessment of what counts as "too disruptive". > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
