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