On Tuesday, October 31, 2017, Guido van Rossum <gu...@python.org> wrote:
> On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan <ncogh...@gmail.com > <javascript:_e(%7B%7D,'cvml','ncogh...@gmail.com');>> wrote: > >> On 31 October 2017 at 02:29, Guido van Rossum <gu...@python.org >> <javascript:_e(%7B%7D,'cvml','gu...@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) >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
