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@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>

">

(original) (raw)


On 26 Sep 2013 07:54, "Barry Warsaw" <barry@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@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
\>