On 26 Sep 2013 07:54, "Barry Warsaw" <ba...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com >
_______________________________________________ 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
