Dijkstra on Python

[James J. Besemer]

Jonathan Hogg wrote:

> "James J. Besemer"<jb at cascade-sys.com> wrote:
>
> > 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.

Nah, this all is just a pipe dream.  Sharing and reusing some idioms is a far cry
from always having "one obvious way to do it."

The saying is clearly a retort in opposition to Perl's "more than one way".  But
in that sense it's intellectually dishonest because the way Perl users usually use
the phrase (e.g., dictionaries vs. lists vs. bitmaps), it, in all fairness,
applies equally well to Python.

Else, what is the "obvious" solution for Sets?  Depends on size, speed, mutability
of elements, etc.  Once you have all the auxiliary requirements, they may lead you
to one solution over the others, but at the level where choices begin to become
meaningful, the same alternatives and trade-offs are available in most languages.

Look at many of the newbie questions on this list: the answers include several
different variations even on trivial problems.

> 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?

No, of course not.  I'm the one saying multiple alternatives (to a point) are a
good thing, not something to be ashamed of.

> 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.

I think the recent addition of list comprehension (wholly redundant with the
others and slowest of the bunch) is a glaring example of "more than one way to do
it."  You can forgive the earlier forms for historical reasons but comprehension
are pure redundancy.  I see them more directly redundant with for/if.

That doesn't make them bad.  But including them DOES violate the rule.  And the
only reason for them that I can see is they're a cute and novel "another way to do
it."

> 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.

I submit if Python did not help people's initial productivity hardly anybody would
use it.  Python DOES help greatly with initial productivity.  This conclusion is
consistent with the many testimonials on this list.

That's not to say Python's simple and uniform syntax doesn't aid maintainability.
Or that initial productivity was a language design goal.  Only that it happens to
be true and it's a good thing.

> 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.

Yeah, Perl sucks.  It's cryptic syntax certainly hurts maintainability.  For me,
it's so screwy that it even hinders initial development.  But that's not the
point.  I"m not saying Perl is good as or better than Python.  I hate Perl.

The only common point between the two languages that I was pressing is that
"there's more than one way to do it" applies equally well to both languages far
better than "only one obvious way" applies to Python.

I only disagree with the the dogma.  I disagree in part because it's not true and
in part because "sound bites" and slogans bring the discussion down to Larry
Wall's level.

> > 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" ;-)

That's a very good point I had overlooked.

I guess it would be easier for me to laugh it off if you and others didn't seem to
believe it so sincerely.

And I don't want to make too big of a deal of this.  It's just a minor nit with me
anyway.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com