Dijkstra on Python
James J. Besemer
jb at cascade-sys.com
Thu Aug 15 13:12:44 CEST 2002
Steve Holden wrote:
> Well, lots of stuff is due to be deprecated, but one of the problems is the
> screams of horror that appear in this newsgroup whenever anything is changed
> in a potentially non-backwards-compatible way.
(a) As Carl explained, the "one way" motto is fundamentally just a "cute
(b) I and others showed examples how in cases where when the underlying
philosophy is applied, it's applied inconsistently and capriciously.
(c) Nobody thus far presented a single example where there's only "one way"
to do something or where it provides any tangible, practical benefit.
All that, balanced with the tangible material hardship non-backwards-
compatible changes present for people trying to maintain existing software,
makes deprecating historic features a POINTLESS and STUPID exercise.
It should only be considered in rare, extreme cases e.g., where it's impossible
to add some significant new feature without breaking some old code. Even
then it should be avoided if there's any alternative.
Non-backwards-compatible changes force the existing installed base to update
their software or else eschew staying up to date with new releases of the
Alternatively, the minority squeaky wheel that cares simply eschews those
features they feel would hinder the readability of their programs. One
alternative impacts practically everybody; the other hardly anybody.
The cost of leaving historic features in is virtually zero. The cost of taking
them out is literally incalculable.
The turmoil in simply arguing about what features to deprecate probably
would consume more energy than any potential "readability cost" savings
of removing them.
It's a Good Thing that the powers that be have generally refrained in the
past from indulging this silly prejudice. I hope they will continue to be
diligent in the future about not breaking old code.
> Me too. I'm hoping that the Python Business Foundation's work to provide
> more stable, longer-lived, Python environments will allow the language to
> keep changing without affecting whatever commercial success it's achieveing.
Non-backwards-compatible changes is a great way to disrupt the
spread of Python into commercial realms.
"Whadda ya mean we can't use the bug-fix version of Python
unless/until we rewrite the code??!!"
I was chided for taking the motto too literally and too seriously and yet
here, later in the same thread, it is cited as the reason to unnecessary
complicate life for the installed base.
It seems ridiculous even to have to defend this point of view.
James J. Besemer 503-280-0838 voice
http://cascade-sys.com 503-280-0375 fax
mailto:jb at cascade-sys.com
More information about the Python-list