<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue., May 21, 2019, 13:07 Neil Schemenauer, <<a href="mailto:nas-python@arctrix.com">nas-python@arctrix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2019-05-21, Terry Reedy wrote:<br>
> The problem with this argument, taken by itself, it that it would argue for<br>
> adding to the stdlib 100s or 1000s of modules or packages that would be<br>
> useful to many more people than the modules proposed to be dropped.<br>
<br>
I don't think it does. We are not talking about 100s or 1000s of<br>
modules. We are talking about modules which have been in Python's<br>
stdlib for years or decades. If I have a script that uses one of<br>
these modules and it gets removed, my script breaks.<br>
<br>
Installing it from PyPI is not really a great solution. We are<br>
going to be breaking working scripts just like if we add new<br>
language keywords, etc. I think we need to be extremely careful<br>
with trying to maintain backwards compatibility, at least as far as<br>
we reasonably can.<br>
<br>
The problem I have with this PEP is that I think it both too<br>
aggressive and too conservative at the same time. For almost all<br>
modules on the list, I'm sure there will be many people who are<br>
harmed by its removal. OTOH, having to maintain all of the modules<br>
in the stdlib is a heavy burden. Also, new users can be lured into<br>
using a module that is not really the best solution anymore.<br>
<br>
Here is an alternative, straw man, proposal. Split the CPython repo<br>
into two parts:<br>
<br>
- core Python: minimal possible stdlib<br>
- everything else<br>
<br>
When Python is released, provide installers for a Python that only<br>
includes the "core" part and a second installer that includes<br>
everything else. I realize this is more work for the release team.<br>
Hopefully with some scripting, it will not be too labour intensive.<br>
<br>
The core Python installer should become the recommended installer.<br>
People who need backwards compability with older versions of Python<br>
can download the big installer package.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">-Brett</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To help the people who need 100s or 1000s of extra PyPI packages, we<br>
could develop a tool that creates a "sumo" Python installer,<br>
grabbing packages from PyPI and building a installer package. To<br>
install that package, you would not need network access. That<br>
doesn't need to happen right away. Also, maybe other Python<br>
distributions can fill that need if core Python devs don't want to<br>
build it.<br>
<br>
Regards,<br>
<br>
Neil<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank" rel="noreferrer">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div></div></div>