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

Nick Coghlan ncoghlan at gmail.com
Thu Sep 26 01:01:12 CEST 2013

On 26 Sep 2013 07:54, "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".

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 at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130926/b22663ba/attachment-0001.html>

More information about the Python-Dev mailing list