On 26 September 2013 14:30, Nick Coghlan <ncoghlan at gmail.com> wrote: > That said, there are changes that I think are definitely worth making > due to the concerns you raise: > > - the module name should be "_ensurepip" in all versions > - the PEP should explicitly state that the "don't remove _ensurepip > and it's wheel files" caveat for redistributors applies only in 3.4+ > (where removing it will break pyvenv) Donald pointed out it makes more sense to continue with the idea of a properly documented public "ensurepip" module in 3.4+, and have the "_ensurepip" version as an implementation detail of the 2.7 and 3.3 installers that is included in the stdlib primarily so it can be covered by the existing buildbot fleet. Redistributors will be free to remove "_ensurepip" from 2.7 and 3.3, but the PEP will continue to advise strongly against removing "ensurepip" from 3.4+ (since it will be a documented feature and a dependency of pyvenv) > The benefits are most obvious in the case of 2.7, so both Donald and I > are also fine with skipping making any changes to Python 3.3. The kind > of environment that could make it difficult to upgrade from Python > 3.3. to 3.4 is unlikely to condone the installation and use of pip > anyway. In replying to Stephen I realised the benefit of making a similar change in the 3.3 installer is that it means the preferred pip bootstrapping instructions for both 2.7 and 3.3 can be to update to the latest maintenance release of CPython, rather than needing to tell 3.3 users to consider upgrading to 3.4 when that release contains potentially breaking changes to the way file descriptors are handled. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4