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

[Guido van Rossum]

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


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


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