Ideally people won't be typing either of them because it'll be installed automatically. They might in some cases (accidentally uninstalled pip?)
I agree that it seems there is paranoia going on here and that the risk is low and making it just be a special cased new feature is ok. However the point of the underscore prefix on 2.7 and 3.3 is to more effectively communicate that on these pythons you shouldn't rely on that module existing. I think that's worse situation then just making it ensurepip everywhere but better than 2.7 not getting it at all or Barry's suggestion. > On Sep 26, 2013, at 10:10 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > Le Thu, 26 Sep 2013 14:54:49 +1000, > Nick Coghlan <ncogh...@gmail.com> a écrit : >> On 26 September 2013 14:30, Nick Coghlan <ncogh...@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. > > Hmm, but what is the point of "_ensurepip" exactly? Are people supposed > to type "python -m _ensurepip"? > > With all due respect, Barry's argument looks rather paranoid to me. > I would suggest a clear choice: > - either having "ensurepip" in 2.7 is useful and we endorse it as a > public module (not something hidden somewhere) - which I personally > think is reasonable > - or it's not useful and we don't introduce it at all > > A middleground doesn't make sense here, except in a broken "design by > committee" sense. > > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
