[Python-Dev] PEP 594: Removing dead batteries from the standard library

Brett Cannon bcannon at gmail.com
Tue May 21 23:04:11 EDT 2019

On Tue., May 21, 2019, 13:07 Neil Schemenauer, <nas-python at arctrix.com>

> On 2019-05-21, Terry Reedy wrote:
> > The problem with this argument, taken by itself, it that it would argue
> for
> > adding to the stdlib 100s or 1000s of modules or packages that would be
> > useful to many more people than the modules proposed to be dropped.
> I don't think it does.  We are not talking about 100s or 1000s of
> modules.  We are talking about modules which have been in Python's
> stdlib for years or decades.  If I have a script that uses one of
> these modules and it gets removed, my script breaks.
> Installing it from PyPI is not really a great solution.  We are
> going to be breaking working scripts just like if we add new
> language keywords, etc.  I think we need to be extremely careful
> with trying to maintain backwards compatibility, at least as far as
> we reasonably can.
> The problem I have with this PEP is that I think it both too
> aggressive and too conservative at the same time.  For almost all
> modules on the list, I'm sure there will be many people who are
> harmed by its removal.  OTOH, having to maintain all of the modules
> in the stdlib is a heavy burden.  Also, new users can be lured into
> using a module that is not really the best solution anymore.
> Here is an alternative, straw man, proposal.  Split the CPython repo
> into two parts:
>     - core Python: minimal possible stdlib
>     - everything else
> When Python is released, provide installers for a Python that only
> includes the "core" part and a second installer that includes
> everything else.  I realize this is more work for the release team.
> Hopefully with some scripting, it will not be too labour intensive.
> The core Python installer should become the recommended installer.
> People who need backwards compability with older versions of Python
> can download the big installer package.

How to this lighten the burden of maintaining those modules which aren't in
the core install? Are you suggesting modules in the core install get
serious focus and the rest is more of a legacy, unsupported release for
some time to give people an extended period to shift to the core install?
Or do you have something else in mind?


> To help the people who need 100s or 1000s of extra PyPI packages, we
> could develop a tool that creates a "sumo" Python installer,
> grabbing packages from PyPI and building a installer package.  To
> install that package, you would not need network access.  That
> doesn't need to happen right away.  Also, maybe other Python
> distributions can fill that need if core Python devs don't want to
> build it.
> Regards,
>   Neil
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190521/20748cfe/attachment-0001.html>

More information about the Python-Dev mailing list