[Python-Dev] python/dist/src/Lib/bsddb __init__.py,1.5,1.6

[Michael Chermside]

[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