[Python-Dev] A house upon the sand

Paul Prescod paulp@ActiveState.com
Mon, 27 Nov 2000 12:14:06 -0800


Mark Lutz wrote:
> 

I read several different issues into your message:

 * standards doc
 * speed of change
 * deprecations
 * backwards incompatibilities

Standards doc: we have one but it is out of date. I think that it would
be great if someone has the bandwidth to improve it but I'm not going to
push Guido very hard to do that because there's a lot of more high
priority stuff I'd like to see him work on.

Speed of change: it wasn't really so radical if you think in terms of
how long these suggestions have been "queued". I would not like it if
Python kept up the same pace of language additions but I don't think
that's going to happen.

Deprecation: deprecations are a good thing. They are the only way that
Python will ever drop old features. If Python never drops old features
then it can only ever grow. If it only ever grows then it will only
become more and more difficult to learn. I don't think I have to justify
the importance of learnability...

Backwards Incompatibilities: I feel strongly that we need to be more
conservative about code breakage. Python 2 was not backwards compatible
enough. It should have deprecated the code and used warnings instead.
Here's my suggested solution for the future:

  http://python.sourceforge.net/peps/pep-0005.html

> A prime example: the string module, used in almost every Python
> program ever written by the half-million Python users out there,
> has suddenly been marked as deprecated.  I expect that it won't
> really go away, but has anyone considered the impact of even the
> suggestion of its deprecation on Python's acceptance?

Sometimes we make mistakes. Making mistakes is part of learning. String
functions should have been methods. We had to correct that mistake. What
other mechanism do we have for correcting mistakes other than
deprecation?

 Paul Prescod