RetroSearch Browse

Thu Sep 26 16:10:46 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-September/128994.html

Le Thu, 26 Sep 2013 14:54:49 +1000,
Nick Coghlan <ncoghlan at gmail.com> a écrit :
> 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.

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-September/128994.html below:

[Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?