ACCEPTED: PEP 285

[Tim Peters]

[Tim, suggests James not pick up new releases more often than he
 feels like upgrading]

[James Logajan]
> 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.

That's a tough one.  I didn't recommend it in this particular thread, but I
do usually recommend that people with extreme compatibility desires ship the
version of Python they're using along with their .py files.  (I know you
don't agree you're "extreme" here, but in the plain statistical meaning you
are.)  Of course I recommend the same to people shipping Perl, Scheme, Icon
or C apps too (note that Python on Windows ships with the specific release
of the Microsoft C libraries it was tested with -- that's one way we try to
insulate Python's users from Microsoft's x-release C incompatibilities,
although it's only partially effective).

> By choosing Tkinter and 1.5.2 I hoped to minimize version
> incompatibility.

I expect that you did!  Good choice.  Your complaint seems to be that
"minimize" turned out to be strictly larger than 0 <wink>.

> 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,

It still is, FWIW:  the Unicode versus Tkinter saga is still unfolding.
Ditto the Unicode versus XYZ story across many languages and many values of
XYZ -- Unicode support is a Huge Change, and especially for projects
predominantly staffed by Americans.  If Python were a commercial project and
could pay users to test in advance of release, I would support doing so.
Instead we did what we could, shipping alpha and beta and release candidates
and begging people to *try* them.  If you didn't pick one of those up to
test your specific cross-release needs, then you missed a great chance to
help yourself.

> 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.

Sure, and I'm sorry you did.  At the same time, I know of no way to stop all
cross-version cross-platform surprises short of stopping Python development
cold.

> 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".

We do our best to meet that in the three-digit "bugfix releases", but
there's still no absolute guarantee.  Any change, even a pure bugfix, *can*
change some program's visible behavior, and sometimes does.  That's a fact,
and can't be wished away.

> 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 expect you phrased that backwards, yes?  If you use a new-in-2.1 feature,
then of course it's not going to run under 2.0.  The other direction is
almost always tractable, although in some cases it does take foresight, or
the active application of hindsight, to pull it off.

> 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.

I think you're determined to take offense, James.  I simply know of no
realistic way to get the extreme level of x-release, x-platform invariance
you want, and regardless of language.  If you think you'll be better off in
this respect using C or Lua or Ruby or whatever, I can can only wish you
luck, and assure you we'll be still be here when you give up <wink>.

I don't brush off your experience, but I do dismiss your implications that
this is something we could easily fix for you if only we didn't hold
Python's users in contempt (or whatever it is you really think).  You could
try using Java instead, which has often *claimed* "write once, run
everywhere (and forever)", but in practice I believe Python gets closer to
meeting that than Java has.  I don't brush off your desire to improve that
situation, but it's true that I don't take it as an absolute good -- it's
one of many competing desires, and one of the hardest to achieve.

> ...
> 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 factor out the Tkinter part of your experience, is that still true?
You hit a really tough knot there.

>> 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?

I doubt that it's relevant unless you view them as realistic alternatives to
Python for x-platform programming.  If so, go right ahead and *try* to write
a real app in csh <wink>.  sh and csh get to stay stable because nobody
wants anything new from them anymore -- they do a small job, and at least
Bourne shell does it well.  Languages like awk, Perl and Python took the
"new feature request" burden off their backs, and gave a large measure of
OS-independence to boot.  I class the Unix shells more with ls and expr
(etc) than with programming languages -- they're more like little tools, and
little tools don't have to grow to survive (GNU's prolific intoduction of
dubious new options notwithstanding).