Booleans, integer division, backwards compatibility; where is Python going?

Guido van Rossum guido at python.org
Sat Apr 6 08:43:19 EST 2002


James Logajan wrote:
> I tried that and that strategy _failed_. The chances of failure was 100%.
> The failure was due specifically to how (as far as I can tell) Tkinter
> handles UTF-8 sequences in Unicode aware versions of Python. So I am forced
> to put version checking into my code! That just added to my irritation.
> There are other _forward_ incompatibilities in Python, but it is the hidden
> ones that misguided programmers are writing into common libraries that make
> the proliferation of Python versions too irritating to deal with.

I sent James a personal reply to this which I'd like to repeat here
(with typos fixed):

"""
I'm sorry that you had a bad experience when Unicode was introduced.
I could probably have done better (I didn't realize that Tcl had a
backwards compatibility feature to deal with Latin-1 strings).

About the change rate in general: it's hard to find the proper pace.
Most new features are requested by users (even the division change!)
and there's definitely a group of users who push for all sorts of new
features -- I say "no" a lot more than "yes"!  I try hard to stay
compatible (that's why the new bool type is not "pure"); I've
introduced things like __future__ statements and warnings that can
help introducing new features without breaking code.  Of course, there
are always tiny corners of the language (or library!) where things
break despite all good intentions, and given the large user base it's
inevitable that there's always *someone* who gets stuck with broken
code.

You clearly fall in the most conservative camp.  I just had a long
exchange with someone who pleaded strongly for moving forward at a
higher pace, breaking more existing code so that the perfect language
can be obtained sooner.  I will have nothing of that, but I hope you
understand my predicament: for every user like you who complains that
things change too fast, there's someone with an equally strong desire
for faster change.  I have to pick a middle ground (and it's easier to
say "don't upgrade" than "wait a year").  Since I'm a language
designer, I enjoy designing new features, but lately each new feature
has cost me probably 10 times more effort to make it backwards
compatible than to design the feature in the first place.  (Examples
besides bool: new-style classes, nested scopes, iterators and
generators all required significant efforts to avoid breaking old
code.)

I don't expect this to satisfy you or to change your mind; I don't
want it to sound like an apology (though it probably does); but I do
hope you understand the forces at work, and I hope you believe I'm
doing the best I can for backwards compatibility.
"""

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



More information about the Python-list mailing list