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

Barry Warsaw barry at python.org
Thu Sep 26 01:04:10 CEST 2013

On Sep 25, 2013, at 06:15 PM, Donald Stufft wrote:

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

I think it's too optimistic to hope that we'll ever see significant
convergence across the Python 2.7 ecosystem.

For example, I'd be really surprised if you'd see this show up in a stable
release of Debian or Ubuntu (the only ones I can speak somewhat
authoritatively about), even if we wanted to cherrypick updates in newer
Python 2.7 point releases.  Linux distros tend to be even more anal about
avoiding new features in stable releases, for the same really good reasons,
IMHO :).

I think for the platforms you're targeting (OS X, Windows), you're going to
see a wide variety for a very long time.  It's depressing how infrequently
people upgrade *anything*.

Another reason to oppose this is what I've heard quite often from people
regarding Python 2.7.  I've been told that many folks are actually really
happy with using 2.7 precisely because it extremely stable.  They don't have
to worry about their stuff breaking or incompatibilities cropping up, because
it *doesn't* change.  Python 2.7 is like a long-term maintenance release, with
guaranteed multi-year stability, and I think while that was unintended, it's a
*good* thing.  This PEP proposes to break that, and I'm loathe to give up that
good reputation for this particular feature.

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

Yeah, maybe, but I'm pretty skeptical about the enthusiasm for upgrades. ;)

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

So, why shouldn't we add enum to the Python 2.7 stdlib?  Or any other new
feature?  Just be aware that if this PEP is accepted for Python 2.7, the bar
will be set much lower for other Really Useful Features That Make Users Lives

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

Cool.  Maybe in the course of that discussion, a better alternative that
doesn't add a new feature to Python 2.7 will present itself.  I really hope

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130925/05772c7d/attachment.sig>

More information about the Python-Dev mailing list