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

Guido van Rossum guido@python.org
Mon, 08 Apr 2002 18:34:45 -0400

But an explicit statement "We aim for a six-month development cycle with one to two months of slop" is better than implicitly gathering as much from a review of documentation release dates (the only handy way I've found to date releases, short of knowing them off your head).

How about the dates mentioned on http://www.python.org/download/ ?

Or PEP 283 (the 2.3 release schedule)?

[on 3.0]

Again, reasonable, but not explicitly announced (or if it has been, it's not vocally announced).

I think you're being unreasonable. Try getting a straight answer from Microsoft on when they'll release the successor to XP. Or Linus when kernel 2.6 will be out.

I'm not at this point looking for comfort, having more or less made my bed. It's nice to find warm sheets, but I'd be stuck with whatever I found. Others are looking for that kind of comfort, though. While this list might have a good idea that "deferred for Python 3.0" means "in 2 years, you'll need to care", I feel like the statement contains a great deal of ambiguity for those who aren't.

It's a big project. It'll probably take longer than expected. We can't predict the future. That's the only answer I can give you without consulting a lawyer for the right amount of weasel words.

> We are already pretty explicit; there are several PEPs about the > process.

I think that considering a PEP as explicit explanation of the process is a lot like expecting cvs log messages to replace Andrew Kuchling's "What's New" summaries.

Now you're being unreasonable again. You don't expect us to do press releases about this, do you?

Maybe what I mean is not explicit. Maybe I should be hunting for another word -- how about "forthright"? That's still not ideal, but the idea is that everyone should know; it should be shouted from the rooftops.

Can't do that. All we have to shout from the rooftops is "Python 3000 is coming". But not when, or what. It's not that we don't want you to know. We don't know it ourselves yet.

I think that PEPs are a great tool when they're not fuel for flames and invective. They're not documentation, though -- they're project proposals. The audience you reach with a PEP is entirely different from the audience I'm suggesting you need to reach with this message.

PEPs also serve as documentation. Just like RFCs, they serve as a specification.

> It depends on the bugfix. Some modules and subsystems are being > refactored in order to provide new features, and then bugfixes won't > port back. Other modules and subsystems are very stable (some could > be called stagnant :-) and will have no problem getting bugfixes > backported.

I think maybe I need to be more concrete about this. The last /appearance/ of stability -- the last time something looked like a fixed target -- was 1.5.2, for whatever reason. Lots of people continue to target 1.5.2, and you can cite a bajillion reasons why they might.

And that's fine with me. I still happily use Windows 98 (I hope that's fine with Bill Gates too :-).

At first occurance of any problem that may or may not be an interpreter bug or a standard library defect, the advice given is to upgrade -- reasonable advice! But that's the suggestion, often without including a recommendation for which of the newer releases to target.

1.5.2 is obsolescent, and it would be very useful for someone who's aiming at 2.2 to know how long his or her company could expect to continue using 2.2 before the first answer to any new problem s/he might experience was "upgrade".

Again, that's impossible to explain without knowing what kind of use they make of Python 2.2, what kind of developers they have, and so on. I think this is to a large extent something that everybody has to decide for themselves. If you have no idea, you might want to ask someone else who is in a similar user category as yourself. But the language developers can't know whether 1.5.2, 2.1 or 2.3 is best for you.

This is a hard assurance to come by, and a hard promise to make in a community as dynamic and "scratch my own itch" as python's (or any open source project, for that matter). Nonetheless, THIS is the stability benchmark that most corporate clients want a sense of.

Too bad. Until they start offering me money, I'm not sure I should care. If someone says "change X or else I will stop using your language", my response is usually "your loss". If someone asks "how much would it cost to change X" I might listen.

> Yes, maybe it can be made to disappear. Does that mean we need to > throw the reactionaries on c.l.py a bone? Is this really all > politics? In that case I'm out of here.

I think it's mostly communication, not politics. The two can be difficult to tell apart, but the former tends to involve telling the truth, a lot; the latter tends to involve telling fibs, a lot. :)

When there's a vocal minority in the newsgroup spreading misinformation about Python's stability (e.g. by continuously whining about the same issues), that's politics too.

To more seriously address your concern, my belief is that people who fear change, fear ambiguity. Managing that fear involves reducing the ambiguity where you can, and demarking the limits of the ambiguity where it can't be removed. The best tool for both tasks is explicit, clear communication. I have tried to identify the places where I see the largest ambiguities looming. My belief is that if these ambiguities are controlled by directly addressing them, some portion of the problems will go away.

I don't think you can have what you're asking for here -- I have no unambiguous answers to your questions beyond "I'm doing the best I can" (or else I wouldn't be spending this entire day reading and responding to email on this topic).

I think that usually, rather than expecting unambiguous answers (which may simply be bluff), you need to listen to the grapevine. Python's grapevine used to be pretty reliable. Unfortunately there's a lot of noise lately. But I can't really think of anything I could say that would be honest and take away the ambiguity. So be it.

I am told that there's a lot of psychological evidence to support this belief, but I haven't done the lit search and am not especially inclined to do so without a compelling reason. :)

I'm trying to be as direct as I can here. I have nothing to hide. The answer simply isn't as clear as you'd like it to be. Tough.

--Guido van Rossum (home page: http://www.python.org/~guido/)