On Tue, 28 Feb 2012 16:23:40 -0500 Chris McDonough wrote:

On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote:

...

2012/2/28 Ethan Furman :

...

Here's what I know:

We don't add features to bug-fix releases. u'' is considered a feature. By not backporting to 3.1 and 3.2 we are not easing the migration pains from 2.x.

Here's what I don't know:

Why is readding u'' a feature and not a bug? (Just had a thought about this -- because the removal of u'' is documented.)

Because it's a new "thing" which doesn't fix obviously broken behavior.

...

If there is already a FAQ entry feel free to point me to it, but I would still be curious why, in this instance, practicality does not beat purity?

Because it's practical not to break bugfix releases with new features.

This change, by its nature, cannot break old programs.

Unless the implementation is buggy, or has unintended side-effects. In theory, *most* changes done in feature releases cannot break old programs. Reality is often a bit more surprising :) Regards Antoine.

On Tue, 2012-02-28 at 16:48 -0500, Barry Warsaw wrote:

On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:

...

...

If there is already a FAQ entry feel free to point me to it, but I would still be curious why, in this instance, practicality does not beat purity?

Because it's practical not to break bugfix releases with new features.

And because now your code is incompatible with three micro-release versions (3.2.0, 3.2.1, and 3.2.2), two of which are bug fix releases. Which means for example, you can't be sure which version of which distro your code will work on.

That I do sympathize with.

Doesn't anybody else remember the True/False debacle in 2.2.1?

I do. It was slightly different than this because the feature was added twice, once in 2.2.1 with direct aliases to 0 and 1, which was found to be lacking, and then later again in 2.3 with explicit types, so it was sort of an extended-timeframe unpleasantness, and the feature's minor-dot-introduction was only a contributing factor, IIRC. But yeah. A year from now I wouldn't remember which version of 3.2 got a new feature, and neither would anybody else. The no-new-features guidelines are useful in the real world this way, because they represent a coherent policy, as tempting as it is to just jam it in. - C

Nick Coghlan writes:

Also, I think there may be some confusion about Armin's plan to handle 3.2 - he aims to write an *import hook* that accepts the u/U prefixes during tokenisation, not a source-to-source transform like 2to3. It's

I must confess, I thought it was a source-to-source transform, because he called it an installation-time hook (which of course makes you think of 2to3) and not an import hook. That will have a much better chance of acceptable performance, since it'll only touch changed stuff automatically. I feel better about the prospects for 3.2 support :-) Regards, Vinay Sajip

On Feb 28, 2012 7:14 PM, wrote:

...

Why is readding u'' a feature and not a bug?

There is a really simple litmus test for whether something is a bug: does it deviate from the specification?

In this case, the specification is the grammar, and the implementation certainly doesn't deviate from it. So it can't be a bug.

I don't think anyone can assert that the specification itself is immune to having "bugs".

Regards, Martin

P.S. Before anybody over-interprets this criterion: there is certain "implicit behavior" assumed in Python that may not actually be documented, such as "the interpreter will not core dump", and "the source code will compile with any standard C compiler". Deviation from these implicit assumption is also a bug. However, they don't apply here.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com

...

There is a really simple litmus test for whether something is a bug: does it deviate from the specification?

In this case, the specification is the grammar, and the implementation certainly doesn't deviate from it. So it can't be a bug.

I don't think anyone can assert that the specification itself is immune to having "bugs".

I can assert that - a specification inherently cannot be "incorrect". It can only be "unintentional". There are certainly documentation errors. They occur when the documentation deviates from the implementation *and* from the intent. They are easy to fix in a bug fix release (assuming the implementation correctly reflects the intent). But then, this isn't the case here, either: the *intent* of the current grammar is that there is no u prefix in the Python 3 language. So the specification clearly corresponds to the intent also. Regards, Martin