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

Guido van Rossum guido at python.org
Tue Oct 31 10:53:08 EDT 2017

On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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.

I don't think that gets you off the hook for a process proposal. We need
some criteria to explain why a module should be on the recommended list --
not just a ruling as to why it shouldn't be in the stdlib.

> 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.

But that would exclude most of the modules you mention below, since one of
the criteria is that their development speed be matched with Python's
release cycle. I think there must be some form of "popularity" combined
with "best of breed". In particular I'd like to have a rule that explains
why flask and Django would never make the list. (I don't know what that
rule is, or I would tell you -- my gut tells me it's something to do with
having their own community *and* competing for the same spot.)

Running the initial 5 proposals through that filter:
> * six: a cross-version compatibility layer clearly needs to be outside the
> standard library

Hm... Does six still change regularly? If not I think it *would* be a
candidate for actual stdlib inclusion. Just like we added u"..." literals
to Python 3.4.

> * setuptools: we want to update this in line with the PyPA interop specs,
> not the Python language version

But does that exclude stdlib inclusion? Why would those specs change, and
why couldn't they wait for a new Python release?

> * cffi: updates may be needed for PyPA interop specs, Python
> implementation updates or C language definition updates

Hm, again, I don't recall that this was debated -- I think it's a failure
that it's not in the stdlib.

> * requests: updates are more likely to be driven by changes in network
> protocols and client platform APIs than Python language changes

Here I agree. There's no alternative (except aiohttp, but that's
asyncio-based) and it can't be in the stdlib because it's actively being

> * 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

I think this needn't be recommended at all. For 99.9% of regular expression
uses, re is just fine. Let's just work on a strategy for introducing regex
into the stdlib.

> 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.

As you can tell from my arguing, the reasons need to be written up in more

> 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.

That's too well hidden for my taste.

> 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.

But that doesn't mean they can't (also) be listed there. (And each probably
has its version dependencies.)

> 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).

Hm, let's not put more arbitrary check boxes in the way of progress. Maybe
it can be an informational PEP that's occasionally updated?

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171031/e25fe966/attachment-0001.html>

More information about the Python-ideas mailing list