[Python-Dev] Re: Stability and change

[Tim Peters]

[Tim]
>> Perhaps you're saying that PLabs should take that over?

[Guido]
> No, this is for all active developers.

How does that differ from PLabs?  There are only a few active developers
outside of PLabs who aren't "one issue" developers, and I wouldn't consider
even *asking* Martin or Michael to take on more than they already do.  If a
new plan involves docs, it necessarily sucks Fred in; if a new plan involves
the PLabs Windows installer, it necessarily sucks me in; and new plan or
old, you're hopelessly sucked in <wink>.  The sum of all active developers
isn't enough to tackle anything truly new.

> I agree that we don't have to change what we do very much, but I'm
> looking for a way to "spin" it to satisfy the more conservative user
> community (the ones who still like Python but are worried about the
> future).

If they write a Python script for 1.5.2, and it doesn't work in Python
58.7.9, they're unhappy.  I'm thinking of Logajan, Cave and Rubin there, as
they're complaining the loudest these days.  They can't be spun into
accepting that any backward incompatibility is defensible.  I assume almost
all of that would go away if incompatible language changes also changed the
extensions used for Python files (like, say, .py3 for Python 3).

> Since there are different "use cases", this may be hard or impossible,
> or we may have to explain it differently for different folks.

A possibility I haven't rejected is give up spin and just acknowledge that
Python can't be all things to all people here:  some people are going to
lose.  Unfortunate, but that's life if so.

> For example, developers who distribute useful Python programs want to
> have a way to ensure that code they write gets run on a compatible
> Python version.

That's not what the people above are saying, though:  they want all future
Pythons to be compatible with everything they wrote 4 years ago.  If a
reasonable <wink> developer appeared who asked for what you're suggesting,
I'd like to try to help them.

> We could make it easier to have different X.Y releases installed on the
> same system; this is already pretty easy on Unix if you know about "make
> altinstall".

I have at least 4 versions of Python installed on each of my Windows boxes,
but there are limits to how deep we can push that (e.g., a given user can
associate .py with at most one interpreter, and before Win2K that was at
most one association per machine; *I* don't care, because I never use any
Windows gimmick that looks at the .py association; if I did care, I'd be
screwed, and because of how Windows works, not because of how Python works).

> If we invent a standard way to specify the required version (or range of
> versions?) then that might be sufficient.  You shot down my #! proposal
> for Windows,

I didn't see that it addressed a real problem.

> but maybe we can do something else.  (Obviously this only works for
> programs, not for modules or packages.  Package authors pretty much
> know the drill.)

There are lots of ways, but I don't have practical experience with any of
them as I'm not change-aversive.  Possibilities include specifying minimal
version numbers required of the language and/or of specific modules at
import sites, relying on a strict backward compatibility guarantee to ensure
that any later version will also work OK; and keeping all old versions of
all modules around in all future releases, viewing specified version numbers
as upper bounds instead of lower bounds.  Another possibility is to work in
terms of versioned interfaces, and rather than import a module directly, ask
the system for any module object that's compatible with a specified version
of a specified interface.

...

>> I don't think anyone is going to buy that as "maintaining" the 2.1.x
>> series; I sure don't.

> Maybe we need to use a different word?  Barry noted that 2.1.x is the
> most popular "stable" release and will probably remain that.  So maybe
> we should say this is the "recommended" release.  And then maybe we
> need to revise the decision not to make a Windows installer.  Or maybe
> we *do* need to spend more effort backporting patches (not necessarily
> PLabs, but *somebody*).

Who?  Anthony Baxter withdrew from the 2.1.x line after 2.1.2 -- he was
tired of doing it.  He popped up again for 2.1.3 under the assurance that it
was going to be a trivial effort.  I have a real problem when a group of
people demands something but won't volunteer anything to make it happen
except their complaints; if they were paying us, fine, but they're not
offering funding either.

> Another way to keep adding value to older releases is by backporting
> the build procedure enhancements.

Isn't this dangerous?  Build config seems very delicate to me.

> Once we've figured out how to build Python 2.3 on, say, some ancient
> version of AIX, maybe somebody should port that back to 2.2 and 2.1.

If they can swear it's not going to break some other Unix mutant, maybe.

> That's not a language change, but still improves the usability of the
> release.  (For some folks.  Maybe the AIX user community is small enough
> that we shouldn't care, but there are other platforms with similar
> issues.  I recall that you backported the new 32 bit Windows installer
> to 2.1.2; maybe the recent fixes could be backported to 2.1.3.)

I was actually reluctant to check those into 2.2.1:  the complaint came from
an XP user, and I don't have an XP box to test it on.  I believe I fixed a
*similar* complaint on my Win2K box, but who knows whether that fixes it for
XP too?  I don't; I can only guess.  Ditto for its effects on ME -- I'm
using installer settings I never tried before, and I can't know whether
there may be a glitch on ME.  It seems to work OK on Win98SE too, so I took
a calculated risk and checked it in to 2.2.1.  But I won't be shocked if it
breaks Windows installation on some version of Windows I don't have.

> OK, so I *am* proposing to do something different.  Maybe it's not
> very attractive to work on old releases.  But Zope Corp does it all
> the time (and the fact that Zope 2.x requires Python 2.1.x may be an
> additional motivator).

If you haven't noticed yet <wink>, you don't control a fraction of the
resource a project of Python's complexity requires.  It's harder to maintain
old Python releases than it is to maintain old Zope releases, because Python
is much closer to the metal:  testing on Linux doesn't say much about what
will happen on HP-UX or Solaris; testing on Windows doesn't say much about
what will happen on Macs; and so on.  Testing a x-platform product requires
a lot of warm bodies and a lot of time.  Without more volunteers, I don't
see it happening.

That said, I'll be happy to build a Windows installer for 2.1.3.  It is,
quite literally, the least I could do <wink>.