Cheers,
Nick.

>
> >
> >
> > 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
>

">

(original) (raw)


On 28 Sep 2013 14:12, "Donald Stufft" <donald@stufft.io> wrote:
\>
\>
\> On Sep 27, 2013, at 11:48 PM, "Stephen J. Turnbull" <stephen@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.

We'll put something in pointing out that accepting this change actually makes it even \*harder\* to advocate for further feature additions in Python 2.7 maintenance releases as there is \*zero\* chance of backporting language changes, and this PEP means library and builtin updates can easily be a pip install away if someone is willing to create the backport and put it on PyPI (Brandon Rhodes already created the "backports" namespace package as a common home for such efforts, or there's the "2" suffix that has been used in a couple of cases).

Cheers,
Nick.

>
\> >
\> >
\> > 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
\>