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

[Nick Coghlan]

On 26 Sep 2013 07:54, "Barry Warsaw" <barry at python.org> wrote:
>
> On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
>
> >I think it should be placed in the source tree for the stable releases.
The
> >reasoning is that 2.7 is going to stick around for a long time.
Immediately
> >this won't be ubiquitous but as time goes on you'll be able to be ensured
> >that a ``python -m ensure pip`` exists so that in situations where you
don't
> >have pip you'll be able to install it.
> >
> >While not directly relevant to the change I do think this is something
users
> >support. I've received a fair but of feedback as I was writing the
original
> >draft of the PEP and then throughout the process when me and Nick
> >were working on it. Almost all of it was positive (some of it extremely
so)
> >a fair bit of them pointed out the backport to 2.7 as something they were
> >*really* wanting.
> >
> >An early draft of this did not have the backport to 2.7 and when I showed
> >*that* version around to get feedback people were less enthusiastic
> >about it and generally viewed it as "nice but worthless to me for N
years".
>
> Yeah, I get all this, but it's essentially the same reasoning that lead to
> Python 2.2.1's addition of True and False.  The same flaw occurs though
> because you cannot guarantee that invocation of `python -m ensurepip` will
> work unless you micro version check (LBYL) or prepare to catch resulting
> errors.  This essentially means that if you want to write portable Python
2.7
> code and scripts, you have to be very cautious, or what works on one box
won't
> necessarily work on another, even though they both have "Python 2.7".

There's a bit of a difference between adding new builtins and adding a new
utility module, though.

The only regular invocations of ensurepip in 2.7 and 3.3 should be from our
installers and people doing a custom build from source.

Would a leading underscore in the module name make you more comfortable
with the idea? It's really intended mostly as a hidden implementation
detail of the installers and pyvenv anyway, so calling it "_ensurepip"
would help make that explicit while still letting people invoke it directly
if absolutely necessary.

Cheers,
Nick.

>
> It also means that anybody who's documenting about this great new feature
has
> to warn people that, well, maybe it won't work on your machine even
though you
> have Python 2.7 because you don't have a new enough Python 2.7.
>
> It means that not all Python 2.7's are alike in a rather fundamental and
> highly visible way.
>
> I personally think that's a recipe for more problems than it solves, and
if I
> was the RM for 2.7 I would not allow it.  But I'm not.
>
> >What users want isn't rationale in and of itself but I think it's an
important
> >data point, especially given how long 2.7.LASTEVER is going to be
> >relevant to end users.
>
> Users want what users want.  It's our job to make the best technical
decisions
> based on all the facts.  I understand that Python 2.7 will be around for a
> long time, and that it would be very convenient to do this.  Why is this
not
> opening up the door to more new features being added in future Python 2.7
> point releases (or any other stable release)?
>
> At least I think the burden should be very high, and the PEP should do a
> better job of explaining why *no* other option will accomplish the goal.
>
> Cheers,
> -Barry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130926/b22663ba/attachment-0001.html>