Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:

> On Sat, 23 Jun 2007 14:56:35 -0400, Douglas Alan wrote:
>
>>> How long did it take you to write the macros, and use them, compared
>>> to running Pylint or Pychecker or equivalent?

>> An hour?  Who cares?  You write it once and then you have it for the
>> rest of your life.  You put it in a widely available library, and then
>> *every* programmer also has it for the rest of their lives.  The
>> amortized cost: $0.00.  The value: priceless.

> Really? Where do I download this macro? How do I find out about it? How
> many Lisp programmers are using it now?

(1) I didn't have to write such a macro for Lisp, as Lisp works
differently.  For one thing, Lisp already has let and set special
forms.  (Lisp uses the term "special form" for what Python would call
a "statement", but Lisp doesn't call them statements since they return
values.)

(2) You act as if I have no heavy criticisms of Lisp or the Lisp
community.  I critique everything with equal vigor, and keep an eye
out for the good aspects and ideas of everything with equal vigor.

> How does your glib response jib with your earlier claims that the
> weakness of Lisp/Scheme is the lack of good libraries?

(1) See above. (2) My response wasn't glib.

> Googling for ' "Douglas Allen" download lisp OR scheme ' wasn't very
> promising.

(1) You spelled my name wrong.  (2) I haven't written any libraries
for any mainstream dialects of Lisp since there was a web.  I did
write a multiple dispatch lookup cacher for a research dialect of
Lisp, but it  was just an exercise for a version of Lisp that few
people have ever used.

> In fairness, the various Python lints/checkers aren't part of the standard
> library either, but they are well-know "standards".

In general I don't like such checkers, as I tend to find them more
annoying than useful.

>> Thanks, but that's just too syntactically ugly and verbose for me to
>> use.

> "Syntactically ugly"? "Verbose"?

> Compare yours with mine:

> let x = 0
> let y = 1
> let z = 2
> set x = 99 

> (Looks like BASIC, circa 1979.)

It looks like a lot of languages.  And there's a reason for that -- it
was a good idea.

> variables.declare(x=0, y=1, z=2)
> variables.x = 99

> (Standard Python syntax.)

> I don't think having two easily confused names, let and set is an
> advantage,

Let and set are not easily confused.  Lisp programmers have had
absolutely no problem keeping the distinction separate for the last 47
years now.

> but if you don't like the word "declare" you could change it to
> "let", or change the name of the module to "set" (although that runs the
> risk of confusing it with sets).

> Because this uses perfectly stock-standard Python syntax, you could even
> do this, so you type fewer characters:

> v = variables
> v.x = 99

> and it would Just Work. 

I wouldn't program that way, and no one that I know would either.

In this regard you sound exactly like all the C++ folks, who when you
point out that something in C++ is inadequate for one's needs, they
point you at some cumbersome and ugly solution and then tell you that
since C++ can already deal with the complaint, that there's no good
reason to consider changing C++.  Consequently, C++ still doesn't have
a "finally" statement, and it requires either making instance
variables public or forcing the programmer to write lots of
boilerplate code writing setter and getter functions.  Fortunately,
the Python developers finally saw the errors of their ways in this
regard and fixed the situation.  But, it seems to me that you would
have been one of those people saying that there's no need to have a
way of overriding attribute assignment and fetching, as you can always
just write all that extra boilerplate code, or instead add an extra
layer of indirection (proxy objects) in your instance data to have
things done the way you want, at the expense of ugly code.

>> Not only that, but my fellow Python programmers would be sure to
>> come and shoot me if I were to code that way.

> *shrug* They'd shoot you if you used "let x = 0" too.

Clearly you are not familiar with the programmers that I work with.
As I mentioned previously, at least one of them is quite upset about
the auto-declaration feature of most scripting languages, and your
suggestion would not make her any happier.

>> One of the reasons that I want to use Python is because I like reading
>> and writing code that is easy to read and looks good.  I don't want to
>> bend it to my will at the expense of ugly looking code.

> But the "ugly looking code" is stock-standard Python syntax.

There many things that cannot be done in stock Python syntax elegantly
(e.g. multiple predicate dispatch), which is why, when programming in
Python, one often sticks to doing things the way that *can* be done
elegantly.  (This can often result in programs that are structured
less elegantly in the large, however.) If you don't recognize this,
then you must be livid over the addition to Python of decorators, list
and generator comprehension, etc.  After, all, Python is Turing
complete, and any problem that can be solved in Python now could have
been solved in Python before.  The solution might just have looked a
little (or a lot) different.

> module.function(keyword=value)
> module.attribute = value

> is precisely the standard Python syntax you describe as "easy to read and
> looks good" one moment. I don't believe you that you find it "ugly looking
> code" -- if you did, you wouldn't be using Python.

It's ugly for the purpose of local variable assignment, as it doesn't
*look* like local variable assignment.  If I wanted to program in a
language that didn't understand the idea that different sorts of
things ought to look different, I'd program in Java, rather than Python.

|>oug