On Sep 27, 2013, at 11:48 PM, "Stephen J. Turnbull" <step...@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@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
