On 29 October 2017 at 19:51, Antoine Pitrou <[email protected]> wrote:
> On Sun, 29 Oct 2017 17:54:22 +1000 > Nick Coghlan <[email protected]> wrote: > > > > The underlying problem is that our reasons for omitting these particular > > libraries from the standard library relate mainly to publisher side > > concerns like the logistics of ongoing bug fixing and support, *not* end > > user concerns like software reliability or API usability. > > They're both really. One important consequence of a library being in > the stdlib is to tie it to the stdlib's release cycle, QA > infrastructure and compatibility requirements -- which more or less > solves many dependency and/or version pinning headaches. > For the QA & platform compatibility aspects, one of the things actually defining a specific extended package set would let us do is to amend the test suite with a new "third-party" resource, whereby we: 1. Named specific known-working versions in the recommended-packages.txt file (updating them for each maintenance release) 2. Added a new test case that installed and ran the test suites for these projects in a venv (guarded by "-uthird-party") > > This means that > > if educators aren't teaching them, or redistributors aren't providing > them, > > then they're actively doing their users a disservice > > Which redistributors do not provide the requests library, for example? > regex is probably not as popular (mostly because re is good enough for > most purposes), but it still appears to be available from Ubuntu and > Anaconda. > The existing commercial redistributors have been doing this long enough now that they offer the most popular third party packages. Where folks can get into trouble is when they're putting their own bespoke environments together based directly on the python.org installers, and that quite often includes folks teaching themselves from a book or online tutorial (since book and tutorial authors are frequently reluctant to favour particular commercial vendors, and will hence direct readers to the python.org downloads instead). > > All the proposal does is to suggest taking those existing recommendations > > from the documentation and converting them into a more readibly > executable > > form. > > I'm curious what such a list looks like :-) > regex and requests are the two cases I'm personally aware of that already have "You'll probably want to look at this 3rd party option instead" links at the beginning of the related standard library module documentation. ctypes should probably have a similar "Consider this alternative instead" pointer to cffi, but doesn't currently have one. All three of those (regex, requests, cffi) have received "in principle" approval for standard library inclusion at one point or another, but we haven't been able to devise a way to make the resulting maintenance logistics work (e.g. bringing in cffi would mean bringing in pycparser, which would mean bringing in PLY...) six should be on the recommended packages list for as long as 2.7 is still supported (and potentially for a while after) setuptools is currently brought in implicitly as a dependency of pip, but would also belong on a recommended packages list in its own right as an enhanced alternative to distutils (https://docs.python.org/3/distutils/ indirectly recommends that by pointing to the https://packaging.python.org/guides/tool-recommendations/ page) Beyond those, I think things get significantly more debatable (for example, while datetime doesn't currently reference pytz as a regularly updated timezone database, most ad hoc scripts can also get away with working in either UTC or local time without worrying about arbitrary timezones, which means that use case is at least arguably already adequately covered by explicit dependency management). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
