[Jeremy]

Isn't this just the sort of little feature that was the subject of recent discussion on the dangers of backporting. It would mean that someone writing an app against Python 2.3 could never be sure whether the feature existed. In practice, that would mean developers using 2.3.x would only find out about problems after deployment when they bump into a user with the original 2.3.

I'm not sure how convincing I find this argument, but it's got some merit.

[Martin]

There is no proper balance. If you believe in the policy "no new features", this policy is absolute - it would be pointless to accept some new features, but reject others on grounds of the policy.

I don't really understand this absolutist position. Suppose (hypothetical example made extreme for retorical purposes) we discover that there was a HUGE bug in release 2.3. Using a variable named "Q" as the argument of a for loop causes the interpreter to seg-fault. This is CLEARLY a bad thing... capital one-letter variable names are uncommon, but not THAT uncommon! So I suppose that 2.3.1 would need to include a fix for this bug. But THEN anyone writing code for 2.3.x could never be SURE whether the bug existed. If they used a capital Q in a for loop, their code would eventually be run by somebody with 2.3.0, causing a crash. The only way to be safe would be to test their code on 2.3.0. How is this "bug fix" any different from a "new feature"? I understand the argument "avoid new features in maintanence releases because there we value stability FAR more than we value features". I understand the argument "avoid new features in maintanence releases because features should be added on the main trunk to encourage the (eventual) use of new versions of Python". But I don't understand the argument "PROHIBIT new features in maintanence releases because then programs written under the maintanence release might not run under the original release", because to me it seems to be logically equivalent to "prohibit maintanence releases". [Martin]

This policy is mutually exclusive with "new features are fine as long as they don't break anything". You can get opinions, but you cannot get consensus.

If "consensus" is taken to mean "universal agreement", then I'd agree, but if we mean "general agreement or accord" (ie, everyone gets heard then NEARLY everyone agrees and the naysayers decide they can live with it), then we might have a shot. I'd certainly say (and I think most here would agree) that even ONE seriously intended firmly held argument against a particular new feature (in a maint. release) would make me think VERY carefully before allowing that feature. -- Michael Chermside