ACCEPTED: PEP 285

[Tim Peters]

[Paul Rubin]
> I don't think he phrased it backwards.  "If you use a new-in-2.1
> feature" presupposes that 2.1 has features that aren't in 2.0, and I
> think James is arguing that it should not.  The issue is just how
> often you're willing to tell people they have to upgrade.

I never tell anyone they have to upgrade:  all choices are tradeoffs, and
you make the ones best for your situation.

> ...
> If I'm running 2.0, and 2.1 comes out, it's pretty similar, so I don't
> upgrade.  Then someone sends me a script that using some new-in-2.1
> feature and I have to upgrade.

This is a tradeoff among your desire to run their script, your reluctance to
upgrade, and your ability to convince that "someone" to code to an older
version of the language.  I don't see "have to" anywhere there.

> ...
> I'd have to do a line by line code review of every one of those damn
> releases before installing it,

Have you done a line-by-line code review of any release?  If not,
multiplication by 0 returns 0 in all versions of Python (so far <wink>).

> ...
> The stability-valuing approach would be DON'T PUT NEW FEATURES into
> releases like 2.1 without good reason to get the particular features
> out fast.

Which competes with other peoples' desires for new features.  I don't buy
that stability is an absolute good; neither new features; overall I've been
very happy with Guido's balancing of these tradeoffs in its effects on my
own code.  I understand that you're not.

> ...
> The proposal of having separate "development" and "stable" release
> tracks like Linux has sounds like a promising direction for keeping
> both camps (language development enthusiasts and would-be production
> users) happier than they are in the current situation.

If we had more active Python developers, that might be feasible.