Dijkstra on Python

James J. Besemer jb at cascade-sys.com
Tue Aug 13 15:45:47 CEST 2002

Carl Banks wrote:

> James J. Besemer wrote:
> [snip]
> I'm sorry, chief, but you are seriously missing the point here.
> First of all, the word "always" is not part of the motto, although you
> seem to be arguing under the premise that it is.  Try importing "this"
> for the canonical (I suppose) version of the statement: "There should
> be one-- and preferably only one --obvious way to do it."
> When Pythonistas say "there should be only one obvious way to do it,"
> we are not saying, "this is how Python is."  We are saying, "this is
> what our programming philosophy is."

I hear what you're saying.  To hold it up as an ideal is one thing.
But  the ideal seems so far from reality that it really strikes me as
somewhat ridiculous when somebody uses the slogan.

And not all people on this list who echo the slogan seem to take it
the way you say.  Mr Hogg's reply seems to include a stronger
interpretation (everybody thinks of the same solution first).
And I've gotten in arguments here where somebody maintained
that Pythonistas' productivity materially suffered if anybody's code
strayed even in the most insignificant fashion from nits in PEP 8
(the overriding "clarity" escape clause notwithstanding).

Lordy, save me!

> When Perlochists say "there's more than one to do it," they are not
> saying, "this is how Perl is."  They are saying, "this is what our
> programming philosophy is."

No.  They're praising PERL for having so many features.  Often
they're furthermore praising a particular developer for coming up
with a solution the first person had never thought of.

In any case, the Perl motto is just plain dumb.  Of course there's
more than one way to do it, so what's the bloody point?

For Python to respond in kind cheapens the discourse.  It lowers
us to their level.  It's a cute sound bite and not bad rhetoric but we'd
do better to rise above it and for the most part simply ignore Perl

> The fact is, both mottos can apply to both languages.  There certainly
> is more than one way to do it in Python.

This was my main point, though I don't agree it's a symmetrical
relationship.  Perl's motto is more applicable to both languages
than Python's is to either.

> And, even in Perl, there is often only one obvious way to do it.

Sometimes, perhaps with enough context, about as often as in
Python or C or C++.

E.g., process all the lines in a file.  With the recent addition of
iterators, "for line in file:" is the pretty obvious choice,
analogous to Perl's "while(<>){".

Oh, wait.  What about file.read() and file.readlines()?  Oops. 3
ways to process a file and probably more.  Seems I can only
come up with bad examples.

> And that really governs the language design of Python.  It means that
> all sinewy little tricks are not strewn through the syntax.

That's fair.  The little tricks, puns and arcane punctuation are
Perl's weakest point and where it contrasts the most with Python.
On the other hand, a lot of Perl's arcane syntax is simply piss
poor language design, not really features.  There's absolutely
no excuse for having the programmer manually track $ and @
"context" in order to get lists.

In any case, you are correct in that The Argument has been
used (for better or for worse) to reject certain proposed
features, such as do-while, "++", "?:", while-getdata, assignment
operators, etc.  My problem is the philosophy is applied inconsistency.

E.g., do-while seems perfectly legitimate and innocent and, given
the present scope of Python, it hardly could be considered a big
change.  It's not uncommon to want to do something at least once
and repeat depending on a trailing test.  It's not overly inventive,
as many languages include the feature. Hell, even Pascal has
repeat-until.  Having an explicit syntax for this fairly common
control flow seems a no-brainer and yet it's been excluded on
"one way" terms (and evidently with great prejudice, based
on some of the comments I've heard on this list).  And yet,
out of the blue, we get list comprehension, which solves no
new problem and is slower than the pre-existing alternatives.
I fail to see how it adds clarity (arguments to that end
notwithstanding), as the inventive syntax and semantics are
going to be unfamiliar to just about everybody, novice and
experienced programmer alike.

So, in practice, "one way" is often just a shield for somebody's
personal prejudice.  Mere rationalization.

> And finally, whether you want to believe it or not, when Pythonistas
> say "there should be only one obvious way to do it," we really are
> talking about common idioms like for loops and switch statements.  No
> one is talking about sets when they say it.

Then perhaps the motto should be "there's less than 5 ways to do it!"  ;o)

Seriously, every time I think I maybe found an example, I then realize
there are 3 or 4 alternatives.  But then, I've only been using Python
regularly for about 4 years now, so what do I know?

So.  I challenge y'all to educate me.  Instead of arguing philosophy,
come up with a concrete list of example problems for which Python
offers only one obvious solution (and of course show the solution).
If this is such a central part of the language design and of the
development community's philosophy, y'all should be able to
whip out, say, 50 or 100 examples off the top of your head.
Note we're confined to "common idioms like for loops and
switch statements" (not higher level problems that would
be even less likely to have unique solutions).

Let's keep this under the current subject and put


at the top of your message.

I've heard the arguments, now show me the data!  I'm genuinely
curious to see how many of you who talk the talk here can
walk the walk -- and if there really is anything at all for which
Python has a genuinely obvious and unique solution.

If we get a good list going, I'll format it into a nice "howto" and
submit it to the powers that be for the benefit of future Pythonites.



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 mailing list