<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 3, 2016, 14:22 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@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 3 July 2016 at 22:04, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> This last bit is what I would advocate if we broke the stdlib out unless an<br>
> emergency patch release is warranted for a specific module (e.g. like<br>
> asyncio that started this discussion). Obviously backporting is its own<br>
> thing.<br>
<br>
It's also worth noting that pip has no mechanism for installing an<br>
updated stdlib module, as everything goes into site-packages, and the<br>
stdlib takes precedence over site-packages unless you get into<br>
sys.path hacking abominations like setuptools uses (or at least used<br>
to use, I don't know if it still does). So as things stand,<br>
independent patch releases of stdlib modules would need to be manually<br>
copied into place.<br></blockquote></div><div><br></div><div>I thought I mentioned this depends on changing sys.path; sorry if I didn't.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Allowing users to override the stdlib opens up a different can of<br>
worms - not necessarily one that we couldn't resolve, but IIRC, it was<br>
always a deliberate policy that overriding the stdlib wasn't possible<br>
(that's why backports have names like unittest2...)<br></blockquote></div><div><br></div><div>I think it could be considered less of an issue now thanks to being able to declare dependencies and the version requirements for pip.</div><div><br></div><div>-brett </div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Paul<br>
</blockquote></div>