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

[Wes Turner]

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

> On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan <ncoghlan at gmail.com
> <javascript:_e(%7B%7D,'cvml','ncoghlan at gmail.com');>> wrote:
>
>> On 31 October 2017 at 02:29, Guido van Rossum <guido at python.org
>> <javascript:_e(%7B%7D,'cvml','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.
>

What about certifi (SSL bundles (from requests (?)) on PyPi)
https://pypi.org/project/certifi/ ?


>
>
>> * 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/devgui
>> de/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/redi
>> stributor-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/3935d037/attachment.html>