<div dir="ltr">Good write-ups. Though it sounds like idna should just be moved into the stdlib. (Agreed that for things like this codecs are not a great idea.) We have other things that must be updated whenever the Unicode standard changes and it seems that doing this in feature releases is typically fine, and treating it as a bugfix (so doing it in bugfix releases is acceptable) sounds fine to me too. Unless it were so security-critical that we'd want to enable users to do such updates to less-supported Pythons or on a tighter schedule (which is one of the reasons requests can't go into the stdlib -- they have their own cert store).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 1, 2017 at 7:36 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Nov 1, 2017 at 7:41 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> Can you write 1-2 paragraphs with the argument for each?<br>
><br>
> On Tue, Oct 31, 2017 at 10:01 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
</span>>> - lxml<br>
<br>
My impression (probably others are more knowledgeable) is that lxml<br>
has more or less replaced the stdlib 'xml' package as the de facto<br>
standard -- sort of similar to the urllib2/requests situation. AFAIK<br>
lxml has never been proposed for stdlib inclusion and I believe the<br>
fact that it's all in Cython would be a barrier even if the<br>
maintainers were amenable. But it might be helpful to our users to put<br>
a box at the top of the 'xml' docs suggesting people check out 'lxml',<br>
similar to the one on the urllib2 docs.<br>
<br>
>> - numpy<br>
<br>
Numpy's arrays are a foundational data structure and de facto<br>
standard, and would probably fit naturally in the stdlib semantically,<br>
but for a number of logistical/implementational reasons it doesn't<br>
make sense to merge. Probably doesn't make much difference whether<br>
python-dev "blesses" it or not in practice, since there aren't any<br>
real competitors inside or outside the stdlib; it'd more just be an<br>
acknowledgement of the status quo.<br>
<br>
>> - cryptography<br>
<br>
Conceptually, core cryptographic operations are the kind of<br>
functionality that you might expect to see in the stdlib, but the<br>
unique sensitivity of crypto code makes this a bad idea. Historically<br>
there have been a variety of basic crypto packages for Python, but at<br>
this point IIUC the other ones are all considered<br>
obsolete-and-potentially-<wbr>dangerous and the consensus is everyone<br>
should move to 'cryptography', so documenting that in this PEP might<br>
help send people in the right direction.<br>
<br>
>> - idna<br>
<br>
This is a bit of a funny one. IDNA functionality is pretty fundamental<br>
-- you need it to do unicode<->bytes conversions on hostnames, so<br>
basically anyone doing networking needs it. Python ships with some<br>
built-in IDNA functionality (as the "idna" codec), but it's using an<br>
obsolete standard (IDNA2003, versus the current IDNA2008, see<br>
bpo-17305), and IIRC Christian thinks the whole codec-based design is<br>
the wrong approach... basically what we have in the stdlib has been<br>
broken for most of a decade and there doesn't seem to be anyone<br>
interested in fixing it. So... in the long run the stdlib support<br>
should either be fixed or deprecated. I'm not sure which is better.<br>
(The argument for deprecating it would be that IIUC you need to update<br>
the tables whenever a new unicode standard comes out, and since it's a<br>
networking thing you want to keep in sync with the rest of the world,<br>
which is easier with a standalone library. I don't know how much this<br>
matters in practice.) But right now, this library is just better than<br>
the stdlib functionality, and it wouldn't hurt to document that.<br>
<span class="HOEnZb"><font color="#888888"><br>
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="https://vorpus.org" rel="noreferrer" target="_blank">https://vorpus.org</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>