[Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
donald at stufft.io
Thu Sep 26 00:15:18 CEST 2013
On Sep 25, 2013, at 5:51 PM, 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".
> 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.
Well I don't think many scripts will be executing ensurepip, maybe i'm wrong,
but yes it does mean that not all Python 2.7's are alike. Most likely though
at some point 2.7.XXX is going to be near standard as the 2.7 hold outs
stay on it and time progresses. It more or less shifts the "time until projects
can assume people have pip available or easily installable" from "until
3.4+ is ubiquitous and 2.7 is gone (Years?) to "until Python 2.7.6 is ubiquitous"
which will be a much shorter time.
>> 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)?
Other than the fact that it in itself is an exception to the rule this actually strengthens
that because it makes it easier for people to install new things into Python 2.7
outside of the release cycle. So things like the new enum module can more easily
be backported and used as an installable than as part of the language. The obvious
exemption to this is language level features, but as this itself isn't a language level
feature i'm not sure how relevant that is.
> 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.
This is totally fair and we can expand on it more for sure.
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Python-Dev