<div dir="ltr"><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important">Thanks for sharing that background, Nick.</p>
<blockquote style="margin:1.2em 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:0px 0px 1.2em!important">Instead, the main step which has been taken (driven in no small part<br>by the Python 3 transition) is the creation of PyPI counterparts for<br>modules that see substantial updates that are backwards compatible<br>with earlier versions (importlib2, for example, lets you use the<br>Python 3 import system in Python 2). </p>
</blockquote>
<p style="margin:0px 0px 1.2em!important">So is the intention that, over the long term, these PyPI counterparts would cannibalize their standard library equivalents in terms of usage?</p>
<p style="margin:0px 0px 1.2em!important">Nick</p>
<div title="MDH:VGhhbmtzIGZvciBzaGFyaW5nIHRoYXQgYmFja2dyb3VuZCwgTmljay48ZGl2Pjxicj48L2Rpdj48
ZGl2PiZndDsmbmJzcDtJbnN0ZWFkLCB0aGUgbWFpbiBzdGVwIHdoaWNoIGhhcyBiZWVuIHRha2Vu
IChkcml2ZW4gaW4gbm8gc21hbGwgcGFydDwvZGl2PjxkaXY+YnkgdGhlIFB5dGhvbiAzIHRyYW5z
aXRpb24pIGlzIHRoZSBjcmVhdGlvbiBvZiBQeVBJIGNvdW50ZXJwYXJ0cyBmb3I8L2Rpdj48ZGl2
Pm1vZHVsZXMgdGhhdCBzZWUgc3Vic3RhbnRpYWwgdXBkYXRlcyB0aGF0IGFyZSBiYWNrd2FyZHMg
Y29tcGF0aWJsZTwvZGl2PjxkaXY+d2l0aCBlYXJsaWVyIHZlcnNpb25zIChpbXBvcnRsaWIyLCBm
b3IgZXhhbXBsZSwgbGV0cyB5b3UgdXNlIHRoZTwvZGl2PjxkaXY+UHl0aG9uIDMgaW1wb3J0IHN5
c3RlbSBpbiBQeXRob24gMikuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TbyBpcyB0
aGUgaW50ZW50aW9uIHRoYXQsIG92ZXIgdGhlIGxvbmcgdGVybSwgdGhlc2UgUHlQSSBjb3VudGVy
cGFydHMgd291bGQgY2FubmliYWxpemUgdGhlaXIgc3RhbmRhcmQgbGlicmFyeSBlcXVpdmFsZW50
cyBpbiB0ZXJtcyBvZiB1c2FnZT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk5pY2s8L2Rpdj48
ZGl2Pjxicj48L2Rpdj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">​</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 4, 2016 at 10:38 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 January 2016 at 12:50, Nicholas Chammas <<a href="mailto:nicholas.chammas@gmail.com" target="_blank">nicholas.chammas@gmail.com</a>> wrote:<br>
> Something else to consider. We’ve long talked about splitting out the stdlib<br>
> to make it easier for the alternative implementations to import. If some or<br>
> all of them also switch to git, we could do that pretty easily with git<br>
> submodules.<br>
><br>
> Not to derail here, but wasn’t there a discussion (perhaps on python-ideas)<br>
> about slowly moving to a model where we distribute a barebones Python<br>
> “core”, allowing the standard modules to be updated and released on a more<br>
> frequent cycle? Would this be one small step towards such a model?<br>
<br>
That discussion has been going on for years :)<br>
<br>
The most extensive elaboration is in the related PEPs:<br>
<br>
PEP 407 considered the idea of distinguishing normal releases and LTS<br>
releases: <a href="https://www.python.org/dev/peps/pep-0407/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0407/</a><br>
PEP 413 considered decoupling standard library versions from language<br>
versions: <a href="https://www.python.org/dev/peps/pep-0413/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0413/</a><br>
<br>
The ripple effect of either proposal on the wider community would have<br>
been huge though, hence why 407 is Deferred and 413 Withdrawn.<br>
<br>
Instead, the main step which has been taken (driven in no small part<br>
by the Python 3 transition) is the creation of PyPI counterparts for<br>
modules that see substantial updates that are backwards compatible<br>
with earlier versions (importlib2, for example, lets you use the<br>
Python 3 import system in Python 2). Shipping pip by default with the<br>
interpreter runtime is also pushing people more towards the notion<br>
that "if you're limiting yourself to the standard library, you're<br>
experiencing only a fraction of what the Python ecosystem has to offer<br>
you".<br>
<br>
We don't currently do a great job of making those libraries<br>
*discoverable* by end users, but they're available if you know to look<br>
for them (there's an incomplete list at<br>
<a href="https://wiki.python.org/moin/Python2orPython3#Supporting_Python_2_and_Python_3_in_a_common_code_base" rel="noreferrer" target="_blank">https://wiki.python.org/moin/Python2orPython3#Supporting_Python_2_and_Python_3_in_a_common_code_base</a><br>
)<br>
<br>
pip's inclusion was also the first instance of CPython shipping a<br>
*bundled* library that isn't maintained through the CPython<br>
development process - each new maintenance release of CPython ships<br>
the latest upstream version of pip, rather than being locked to the<br>
version of pip that shipped with the corresponding x.y.0 release.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</blockquote></div>