Eliminating upgrade risk

[Tim Peters]

[James C. Ahlstrom]
> The problem is that the new Python features, as wonderful as they are,
> are chosen for Computer Science Purity, not day-to-working-day
> importance to someone actually trying to write a widely used bullet
> proof program.

[Tim Peters]
> As my physicists friend like to say, "that's not even wrong".
> Write a PEP.

[James Logajan]
> Are you seriously suggesting he write a PEP to inhibit the other PEPs?
> Or are you demanding something else?

Such point as there was was two-fold:

1. The idea that Python features are chosen for "Computer Science Purity"
   is so far off base it's "not even wrong".

2. The PEP process is the place to flesh out future language directions,
   and is open to everyone.  If someone (named James or not) wants a
   change of any kind, they should write a PEP; venting on c.l.py may
   or may not feel good, but probably isn't going to accomplish anything.
   So "write a PEP" was advice, not a demand.  I didn't have in mind a
   PEP opposing other PEPs, but a PEP fleshing out something specific
   that would be of "day-to-working-day importance to someone actually
   trying to write a widely used bullet proof program."  Robin Becker
   suggested that the ability to split lists fell in that category <wink>,
   but I'm sure I have scant idea what it means to JimA.

>> while-compsci-purists-denounce-python-for-its-pragmatism-ly y'rs  - tim

> I've checked the Google archives, and I've come to the conclusion that
> you are of the position that anyone who doesn't constantly upgrade
> should not be supported, in the sense that if they report bugs, write
> books about Python, or ask for porting assistance, their questions will
> all be answered with "Upgrade first, then we'll talk". Is that basically
> correct?

In *most* cases advice to upgrade is met with "Thanks! That solved the
problem.".  So of course that's always my first suggestion, for cases that
upgrades can solve.  The idea that I'd say "upgrade first" to someone
writing a book doesn't make sense, so I'll skip that one.

If a user with a bug or a porting problem can't upgrade, it depends on the
specifics.  There was never a bugfix release for 1.5.2, so there *usually*
isn't much else to be said to people who had deep problems with 1.5.2.  I'm
very happy the community (in the persons of Moshe Zadka and Thomas
Wouters -- and special thanks to Aahz for championing the PEP that made it
possible!) volunteered to produce bugfix releases for 2.0 and 2.1.  When
closing a bug via "fixed in 2.0" on SourceForge, or reporting on c.l.py that
a bug has been so closed, the correct way to read that isn't "upgrade or
die", it's "so it will show up in the appropriate follow-on bugfix
release -- provided volunteers step up to produce one".

For people who can't deal with that either, what would you like me to do?
I'm paid to work on "the next" release, including but pretty much limited to
repairing bugs discovered in prior releases, and for my own (unpaid) Python
work don't even keep old versions of Python sitting around.  That doesn't
mean I never volunteer "spare time" to help people who have problems with
old versions, but most days, yes, I'd rather go see a movie.

although-i-haven't-had-time-for-that-in-about-3-months-ly y'rs  - tim