<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 4 Jan 2016 at 21:22 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 14:14, Nicholas Chammas <<a href="mailto:nicholas.chammas@gmail.com" target="_blank">nicholas.chammas@gmail.com</a>> wrote:<br>
> Thanks for sharing that background, Nick.<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).<br>
><br>
> So is the intention that, over the long term, these PyPI counterparts would<br>
> cannibalize their standard library equivalents in terms of usage?<br>
<br>
Probably not - the baseline versions will almost certainly always be<br>
used more heavily simply due to being available by default.<br>
<br>
What the PyPI releases mean is that the folks for whom the standard<br>
library version is old enough to be annoying now have the freedom to<br>
choose between selectively updating just that component and upgrading<br>
to a new version of the language runtime, and the former is important<br>
when you don't have full control over the target runtime environment<br>
(e.g. many folks are paid to support the system Python runtimes on<br>
various versions of Linux, and only drop support for those old<br>
versions when the Linux vendors do).</blockquote><div><br></div><div>If you guys wants to continue this conversation, the stdlib-sig is the perfect place to have this discussion. </div></div></div>