[Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
donald at stufft.io
Sat Sep 28 06:12:50 CEST 2013
On Sep 27, 2013, at 11:48 PM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Nick Coghlan writes:
>> You have confirmed my belief that your model is incorrect.
> *shrug* I just think the risks are higher than acknowledged (just
> because you have so far failed to imagine a problem doesn't mean it
> won't appear), and that the meta effect that "Even Guido admits that
> Python 3 isn't ready for prime time" is perverse. We know, even those
> who have written blanket statements to that effect in this thread,
> that that is false unless conditioned on specific applications.
I haven't seen anyone say Python 3 isn't ready to be used, just that it
makes more sense for beginners to use 2.7, and I think it does still.
Porting libraries from 2.x to 3.x and translaing the existing corpus of
tutorials, tips, posts, etc isn't a trivial task and one that beginners
are unlikely to grok.
> I understand that the real motivation is that it's churlish to not
> relieve the pain of users who have decided for their own good reasons
> to use Python 2.7, and perverse to ignore the needs of the teachers
> who are going to educate the users about Python 3 at the time they
> consider appropriate. But the meta-message *received* by the public
> is not going to accurately reflect that motivation, and is not going
> to be helpful in encouraging those who already *can* move to Python 3
> to do so.
> Anyway, clearly this exception is heading for approval, and the PEP
> with it. I recommend that the "Feature addition in maintenance
> releases" section be amended to read in its entirety:
> The additions of the new module to the standard library in the
> maintenance releases of 2.7 and 3.3 were granted explicit
> exceptions to the rule "no new features in maintenance releases."
> These exceptions were explicitly discussed, and approved in
> consultation with the affected release managers, separately from
> the rest of the PEP. They do not represent a change in policy,
> and must not be considered a precedent for other such exceptions.
> Just the facts, ma'am. It's a bad idea to include bullshit about the
> benefit-cost ratio, because it will be cited in future requests for
> similar exceptions. To the extent that people interpret this as a
> forecast and support for a long life for Python 2.7, there is
> substantial risk of such requests.
Maybe my understanding of the PEP process is flawed, but isn't
part of the point of it to codify the *reasons* for the decisions that
were made? That's why they include information about dissenting
opinions and such?
I don't think it's dangerous to cite the reasons the decision was came
to. Perhaps it can be toned down but I think it's useful to document
the discussion. I've got a partially done update that tries to capture
the dissenting opinions as well for completeness sake.
>  I do it that way myself, always with the most recent Python 3,
> but haven't yet gotten to the point of needing "pip" (use cases that
> happen to be met by the stdlib).
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Python-Dev