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

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

Footnotes: [1] 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 https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mail.python.org/pipermail/python-dev/attachments/20130928/58a78cf8/attachment-0001.sig>

More information about the Python-Dev mailing list