<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 October 2017 at 09:31, MRAB <span dir="ltr"><<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2017-10-28 22:05, Guido van Rossum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span><div><div class="h5">
I don't condone having two different regex implementations/APIs bundled in any form, even if one were to be deprecated -- we'd never get rid of the deprecated one until 4.0. (FWIW I don't condone this pattern for other packages/modules either.) Note that even if we outright switched there would *still* be two versions, because regex itself has an internal versioning scheme where V0 claims to be strictly compatible with re and V1 explicitly changes the matching rules in some cases. (I don't know if this means that you have to request V1 to use \G though.)<br>
<br>
The other problem with outright replacement is that despite Matthew's best efforts there may be subtle incompatibilities that will break people's code in surprising ways. I don't recall much about our current 're' test suite -- I'm sure it tests every feature, but I'm not sure how far it goes in testing edge cases. IIRC this is where in the past we've always erred on the side of (extreme) caution, and my recollection is of Matthew being (understandably!) pretty lukewarm about doing extra work to help assess this -- IIRC he's totally fine with the status quo.<br>
<br>
If there's new information or a change in Matthew's outlook I'd be happy to reconsider it.<br>
<br>
</div></div></blockquote>
At one time I was in favour of including it in the stdlib, but then I changed my mind. Having it outside gives me more flexibility, and I'm happy with just using pip.<br></blockquote><div><br></div><div>OK, so I think that leaves the notion of a "Recommended baseline package set" as the most realistic option we have for improvement in this area - coming up with a way for us as the standard library maintainers to make particular 3rd party components more readily available to end users, while also providing explicit guidance to 3rd party redistributors that we think those components should be offered by default in general purpose scripting environments.</div><div><br></div><div>I'll start a thread on python-ideas about that, as I think we could get quite some way towards that goal with just some minor additions to the ensurepip and venv modules (using existing documented third party recommendations like those in the re docs for regex and the urllib.request docs for requests), without actually bundling anything directly into the <a href="http://python.org">python.org</a> installers.<br></div><br></div>Cheers,</div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>