ACCEPTED: PEP 285

[James Logajan]

Tim Peters <tim.one at comcast.net> wrote:
> It's unclear why you would ever need to, if you want to stick with an
> older version, unless you wanted to pick up a pure bugfix release (a
> 3-digit release, like next week's upcoming 2.2.1 and 2.1.3, being,
> respectively, the first pure bugfix release in the 2.2 series, and the
> third in the 2.1 series).

Your advice may seem reasonable but wasn't quite applicable. I developed 
some Usenet moderation programs on 1.5.2 because I knew the co-moderators 
would be running on Linux (1.5.2 and 2.0), Solaris (1.5.2), and Windows 
(2.1). I didn't have Solaris handy, so by distributing this freeware 
program as a simple zipped file of *.py files, I wouldn't have to contend 
with the near impossible task of freezing my application on all the target 
platforms. And with luck it could be used by users running on Macs. By 
choosing Tkinter and 1.5.2 I hoped to minimize version incompatibility. But 
in the end I had to contend with unexpected forward incompatibilities in a 
few places, including in sockets (this one was well known, still some old 
code tripped me up), cStringIO's close semantics changed, and of course 
Tkinter problems. The Tkinter issue was more vexing than the other issues, 
since it took a while to surface and when it did it took a while to track 
down and come up with a good solution. I guess you could say I got "burned" 
by it.

> Major releases change the first digit; there have been only three such
> in all of Python history, counting 0.9.6 and 1.0 and two major
> releases. Python 3.0 is at least years away.  The goal between minor
> releases (bumping the 2nd digit) is 6 months.

Sorry, I meant to use "major" here as in "there are new features or 
semantic changes in this release that if you use in your code, it wont run 
at all or as you expect on previous releases". Doesn't matter what you call 
it, if a 2.1 script can't run at all or as expected on 2.0, that is a major 
change in the _colloquial_ sense. I consider the nature of the changes 
between so-called "minor" releases and their frequency a major problem to 
_me_. I don't think you can realistically "argue" those problems away. I am 
hoping that you will try to accommodate my experiences into your Python 
world view before brushing them off.

> Why do you feel you can't slow down your adoption of new releases? 

Before I set Python aside as being unacceptably non-portable for a 
scripting language, I _had_ tried to stop at 1.5.2. But I couldn't develop 
open source scripts in such a way that they were version independent 
without either a lot of version checking or freezing applications with a 
specific version of the interpreter (which defeats one of the points of 
open source IMHO).

> If you only
> care to upgrade every 2 or 3 years (whatever), you're not required to
> pick up releases any faster than that.  It's not like you paid us for a
> subscription and are going to get cheated out of your money's worth if
> you refuse to accept delivery <wink>.

My last Python project was a freeware moderation tool: my attempt to 
contribute some small thing back to the maintenance of Usenet. It was the 
difficulties encountered in that project that made me think about the 
future of Python and my use of it.

> When the release rate slows to what you'd like to see, I'd take it as a
> strong indicator that Python may be entering its death phase.

The Bourne shell (bsh) and C shell (csh) haven't changed in a _long_ time. 
Do you consider these scripting languages dead in any meaningful sense of 
the word?