[Python-ideas] Defining an easily installable "Recommended baseline package set"

[Nick Coghlan]

On 31 October 2017 at 02:29, Guido van Rossum <guido at python.org> wrote:

> What's your proposed process to arrive at the list of recommended packages?
>

I'm thinking it makes the most sense to treat inclusion in the recommended
packages list as a possible outcome of proposals for standard library
inclusion, rather than being something we'd provide a way to propose
specifically.

We'd only use it in cases where a proposal would otherwise meet the
criteria for stdlib inclusion, but the logistics of actually doing so don't
work for some reason.

Running the initial 5 proposals through that filter:

* six: a cross-version compatibility layer clearly needs to be outside the
standard library
* setuptools: we want to update this in line with the PyPA interop specs,
not the Python language version
* cffi: updates may be needed for PyPA interop specs, Python implementation
updates or C language definition updates
* requests: updates are more likely to be driven by changes in network
protocols and client platform APIs than Python language changes
* regex: we don't want two regex engines in the stdlib, transparently
replacing _sre would be difficult, and _sre is still good enough for most
purposes

Of the 5, I'd suggest that regex is the only one that could potentially
still make its way into the standard library some day - it would just
require someone with both the time and inclination to create a CPython
variant that used _regex instead of _sre as the default regex engine, and
then gathered evidence to show that it was "compatible enough" with _sre to
serve as the default engine for CPython.

For the first four, there are compelling arguments that their drivers for
new feature additions are such that their release cycles shouldn't ever be
tied to the rate at which we update the Python language definition.


> And is it really just going to be a list of names, or is there going to be
> some documentation (about the vetting, not about the contents of the
> packages) for each name?
>

I'm thinking a new subsection in
https://docs.python.org/devguide/stdlibchanges.html for "Recommended Third
Party Packages" would make sense, covering what I wrote above.

It also occurred to me that since the recommendations are independent of
the Python version, they don't really belong in the version specific
documentation.

While the Developer's Guide isn't really the right place for the list
either (except as an easier way to answer "Why isn't <X> in the standard
library?" questions), it could be a good interim option until I get around
to actually writing a first draft of
https://github.com/python/redistributor-guide/ (which I was talking to
Barry about at the dev sprint, but didn't end up actually creating any
content for since I went down a signal handling rabbit hole instead).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171031/e3168264/attachment.html>