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

Donald Stufft 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.

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/donald%40stufft.io

Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mail.python.org/pipermail/python-dev/attachments/20130925/8cc17b8c/attachment.sig>

More information about the Python-Dev mailing list