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 Better. >> 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 so. -Barry
signature.asc
Description: PGP signature
_______________________________________________ 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/archive%40mail-archive.com
