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

Donn Cave donn at drizzle.com
Sat Apr 6 14:17:51 EST 2002


Quoth Guido van Rossum <guido at python.org>:
...
| 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").

I sure fail to see the point of this middle ground.  On one hand, you
have a language that is manifestly very useful to programmers in a variety
of disciplines but fails to be the perfect language.  On the other, you
have a vision of the perfect language, which in principle ought to be
more useful but definitely will break some significant amount of code
written today.  In between, you have all the problems of both - breaks
code today, doesn't prevent tomorrow's breakage, and isn't the perfect
language anyway.  Major Python heads fight tooth and nail against changes
that they might well accept without complaint as features of a really
overhauled language.  Developers turn away, platforms like Redhat who
could ship Python are put in a difficult position.  In the present release
schedule, "don't upgrade" may be easy to say but it isn't really supported -
neither at the core, where Tim's quick to point out that we're on our own
for bug fixes, nor among the external contributors who have no notion that
any such thing is going on, nor among client sites who are apt to install
whatever's current.  Is this fun?  Doesn't sound like it.  Will it be more
fun to artificially prolong the process?  Surely it will not.  Why not
just do what you have to do, and concede that a few releases hence will
be bleeding edge, not for general production use?

	Donn Cave, donn at drizzle.com



More information about the Python-list mailing list