[Python-Dev] Re: Stability and change

[Guido van Rossum]

> 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/)