Home Original page

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

Glenn Linderman v+python at g.nevcal.com
Wed May 22 14:56:55 EDT 2019 
Between this discussion and Steve Dower's recently referenced blog post 
at 
https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/from 
which I quote below:

> It’s been widely known for many years that Windows is the only 
> mainstream operating system that does not include a Python interpreter 
> out of the box.

and Victor's and Eric's work to make embedding Python easier, it makes 
me wonder when emacs will include a Python interpreter as an extension 
language.


On 5/22/2019 2:26 AM, Stephen J. Turnbull wrote:
> Neil Schemenauer writes:
>
>   > Here is an alternative, straw man, proposal.  Split the CPython repo
>   > into two parts:
>   >
>   >     - core Python: minimal possible stdlib
>   >     - everything else
>
> I take issue with the characterization of "straw man," it's a
> practical idea that turns out to be not so easy to implement.
>
> We tried to do this with XEmacs, and found it just didn't work for us.
> It requires a lot of effort to pare a distribution down to a minimal
> core.  (In fact, we never got close.)  We gave up on that idea after
> only a year, and this was an age and an environment that did not have
> pip-like support for installation of 3rd-party packages (which you
> deprecate as "not really a great solution"), and a lot of people were
> still downloading at ISDN speeds or worse.  The demand for a minimal
> core was correspondingly greater than today, I think.
>
> We did bundle most applications such as MUAs and even C/C++
> development support into sumo packages (one for general use, one for
> packages that didn't function at all without the "MULE" multilingual
> environment which was optional in XEmacs).  But we still ended up with
> many packages staying in the core distribution, because other parts of
> the core or the installation process used them, and as you say "If I
> have a script that uses one of these modules and it gets removed, my
> script breaks."  That annoyed core developers as much as anyone, and
> they generally had priorities that did not emphasize minimalism (to
> say the least).
>
>   > 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.
>
> Creating the distributions (core and sumo) was not particularly
> labor-intensive for us because we mostly didn't distribute binaries.
> A few moderately baroque scripts did the trick.  Automation has
> advanced, but due to the amount of it it's still fragile, especially
> when you're producing turn-key binary installers.
>
> As I mentioned above, it wasn't the release process that was the
> bottleneck, it was other factors that made it hard to reduce the
> core.  We had an "xemacs-base" package that provided a set of "extra
> tools" that some packages required, and libraries moved in and out of
> it pretty much every release as some developer got tired of telling
> people to install xemacs-base (back to core) or working around missing
> features (move it to xemacs-base where it could be updated easily).
>
> These are the same things that Python maintainers mention as pros and
> cons of having things in stdlib or out on PyPI.  We learned there is a
> sweet spot.  I know we didn't hit it most of the time, but it's very
> clear that both extremes are hard, if not infeasible, to maintain.
> (At the maximalist extreme, even GNU Emacs doesn't really try to
> include everything written in Emacs Lisp any more.)
>
>   > 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.
>
> This could be done by any third party (it wouldn't even need to be a
> public distribution, it could easily be an enterprise that open
> sources an internal tool or a GSoC project).  And it could be hosted
> on PyPI itself, since it's not the kind of thing that enterprises need
> to install on 100,000 workstations.
>
>   > To install that package, you would not need network access.
>
> AIUI, it's not the network access that is usually the problem these
> days, although it can be annoying if net access is flaky or if you
> have to sneakernet USBs around.  Still, "sneakernet" is basically a
> one-off cost.  The problem is that collections of random software from
> untrusted sources are verboten in the enterprise.  (Ah, those Walnut
> Creek CDs were wonderful!  I wonder what a modern AV tool would find
> in them?!)  I suppose that in those situations people already have the
> necessary tooling to roll the sumo or provide an intranet repository;
> the problem is navigating the red tape.
>
>   > 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.
>
> I don't think this is about what core devs do or don't want to build.
> I also don't feel a strong sense among the core developers that they
> don't want to maintain a "batteries included" standard library.  Sure,
> there's Christian's PEP, but there's also deliberate activity to
> promote more participation at the core (ie, committer) level.  AIUI,
> Christian's PEP is about transparency of what is already happening
> (WONTFIX-ing or long periods of inactivity on issues with modules of
> "low importance" to the active core developers), and a first step
> toward making a managed process for the deprecation of modules we
> can't afford to maintain given others we have committed to maintain.
>
> Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190522/b3190044/attachment.html>
More information about the Python-Dev mailing list