Dijkstra on Python

[Jonathan Hogg]

On 13/8/2002 4:56, in article
mailman.1029211160.24826.python-list at python.org, "James J. Besemer"
<jb at cascade-sys.com> wrote:

> Al Vining [and many others] write:
> 
>> "There should be one -- and preferably only one
>> -- obvious way to do it."
> 
> I have a problem with this particular particle of Python dogma.
> 
> My chief problem is that it's every bit as meaningless and ridiculous as
> when Larry Wall promotes the "other" way of doing things.
[...]
> So, plainly, "there's more than one way" to solve most problems in any
> modern programming language.

Of course, but the statement is frequently misread. It says that there
should be one *obvious* way to do it. The point is that the first solution
that occurs to you should be the same as the first solution that would have
occurred to another Python programmer.

Having done it the obvious way and not achieved the required solution by
whatever metric (perhaps performance), you should try doing something
another way.

It's quite possible that the obvious way that occurred to you is less
obvious to someone else because of differences in your and their experience.
Through discourse here, and things like the Python Cookbook, we tend towards
the same patterns of programming Python.

> However, Python itself breaks its own rules at the low level; e.g. with
> 
>   for
>   while
>   map, et al.
>   list comprehension
> 
> ... Python offers at least 4 redundant ways to iterate over a collection.

Depending on the purpose of the iteration, hopefully one of these will seem
the more obvious choice than the others. Do you find yourself spending much
time agonising over which to use?

I'd say the only ones that overlap in any great respect are map/filter and
list comprehensions. Arguably, list comprehensions are now considered the
more Pythonic solution.

> Now, IMO this is a GOOD thing, not a bad one.  Having a narrow variety of
> choices for things like this is good for the programmer.  Larry Wall makes a
> small point in that productivity will be higher if the language already
> provides the mechanism the programmer first thinks of or is most familiar
> with.

One problem that Python attempts to aid is not a programmer's initial
productivity in writing the code, but his/her or another's subsequent
productivity in maintaining it.

Perl usage tends to be so idiosyncratic that I've known Perl programmers who
couldn't read their *own* code after a while, let alone the difficulty in
reading someone else's Perl.

> Thus, in practice, this particular rallying call is every bit as meaningless
> as Perl's.

Which is perhaps why The Zen of Python should be filed under "humour" ;-)

Jonathan