[Python-Dev] Re: Stability and change (original) (raw)

Tim Peters tim.one@comcast.net
Sun, 07 Apr 2002 19:49:51 -0400

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