<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">My thinking on this issue was that some/most packages from the stdlib would move into site-packages. Certainly I'd expect asyncio to be in this category, and probably typing. Even going as far as email and urllib would potentially be beneficial (to those packages, is my thinking).<br><br>Obviously not every single module can do this, but there are plenty that aren't low-level dependencies for other modules that could. Depending on particular versions of these then becomes a case of adding normal package version constraints - we could even bundle version information for non-updateable packages so that installs fail on incompatible Python versions.<br><br>The "Uber repository" could be a requirements.txt that pulls down wheels for the selected stable versions of each package so that we still distribute all the same code with the same stability, but users have much more ability to patch their own stdlib after install.<br><br>(FWIW, we use a system similar to this at Microsoft for building Visual Studio, so I can vouch that it works on much more complicated software than Python.)<br><br>Cheers,<br>Steve<br><br>Top-posted from my Windows Phone</div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:p.f.moore@gmail.com">Paul Moore</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">7/3/2016 14:23</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:brett@python.org">Brett Cannon</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Cc: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:guido@python.org">Guido van Rossum</a>; <a href="mailto:ncoghlan@gmail.com">Nick Coghlan</a>; <a href="mailto:python-dev@python.org">Python-Dev</a>; <a href="mailto:steve.dower@python.org">Steve Dower</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)</span><br><br></div>On 3 July 2016 at 22:04, Brett Cannon <brett@python.org> 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><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><br>Paul<br></body></html>