<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 October 2017 at 19:51, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Sun, 29 Oct 2017 17:54:22 +1000<br>
Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> The underlying problem is that our reasons for omitting these particular<br>
> libraries from the standard library relate mainly to publisher side<br>
> concerns like the logistics of ongoing bug fixing and support, *not* end<br>
> user concerns like software reliability or API usability.<br>
<br>
</span>They're both really. One important consequence of a library being in<br>
the stdlib is to tie it to the stdlib's release cycle, QA<br>
infrastructure and compatibility requirements -- which more or less<br>
solves many dependency and/or version pinning headaches.<br></blockquote><div><br></div><div>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:</div><div><br></div><div>1. Named specific known-working versions in the recommended-packages.txt file (updating them for each maintenance release)<br></div><div>2. Added a new test case that installed and ran the test suites for these projects in a venv (guarded by "-uthird-party")<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-">
> This means that<br>
> if educators aren't teaching them, or redistributors aren't providing them,<br>
> then they're actively doing their users a disservice<br>
<br>
</span>Which redistributors do not provide the requests library, for example?<br>
regex is probably not as popular (mostly because re is good enough for<br>
most purposes), but it still appears to be available from Ubuntu and<br>
Anaconda.<br></blockquote><div><br></div><div>The existing commercial redistributors have been doing this long enough now that they offer the most popular third party packages.</div><div><br></div><div>Where folks can get into trouble is when they're putting their own bespoke environments together based directly on the <a href="http://python.org">python.org</a> 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 <a href="http://python.org">python.org</a> downloads instead).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-">
> All the proposal does is to suggest taking those existing recommendations<br>
> from the documentation and converting them into a more readibly executable<br>
> form.<br>
<br>
</span>I'm curious what such a list looks like :-)<br></blockquote><div><br></div>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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">ctypes should probably have a similar "Consider this alternative instead" pointer to cffi, but doesn't currently have one.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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...)</div><br><div class="gmail_quote">six should be on the recommended packages list for as long as 2.7 is still supported (and potentially for a while after)</div><div class="gmail_quote"><br></div><div class="gmail_quote">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 (<a href="https://docs.python.org/3/distutils/">https://docs.python.org/3/distutils/</a> indirectly recommends that by pointing to the <a href="https://packaging.python.org/guides/tool-recommendations/">https://packaging.python.org/guides/tool-recommendations/</a> page)<br></div><br><div class="gmail_quote">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).</div><div class="gmail_quote"><div class="gmail_quote"><br></div></div>Cheers,</div><div class="gmail_extra">Nick.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia</div>
</div></div>