Zen of Python

[Paul Prescod <address@hidden>]

Paul Graham wrote:
> 
>...
> 
> The question at hand is, can a *language* be too succinct?
> I.e. can you design a language that forces users to
> express their programs in an excessively dense style,
> rather than (like any language) merely allowing them to?

A language can *encourage* either an overly succinct or clear style.
That's the point we've been dancing around. When you asked Python to do
something that was against general Python programming practice (mutate a
closure) it rebelled. Usually that will make a Python programmer think:
"gee, I wonder if there is another way I should be doing this...in this
case a class."

It's the same with the statement/expression dichotomy. Python cannot
stop you from making deeply nested expressions. But it can make it
easier to pop back out to a statement than to keep nesting the
expression.

Many Python programmers wanted a feature to allow you to inspect your
caller's stack and figure out what variables are available there. Power
users wanted the feature to do macro-like and debugger-like things.
Newbies wanted the feature because they didn't understand that it is
better to refactor the code and pass in the variable rather than trying
to figure out the context by sticking your head through the roof. So
Guido put the feature in, but hid it and gave it an obscure name that
would be accessible to the people who would know how to use it, but
inscrutable to those who would accidentally use it to destroy their
program's maintainability.

You have to understand that thousands of programmers choose Python
because it helps them to program better and more important, helps the
people they program with to program better.

> I have not seen any evidence for succinctness and
> readability (overall readability, not readability-per-line)
> pulling in different ways at the level of language design.
> Got any evidence of that?  Let us know.

I don't want to pick on Perl but we cannot consider the issue of
conciseness and flexibility versus readability without comparing these
two siblings. The two communities have a lot of immigration between them
so we have the testimonies of real programmers.

Many people (especially "occasional" scripters who may spend most of
their day job in Java or fluid dynamics) testify that they switched
language because in the more flexible, succinct language, they "cannot
read their own code months later." I mean there are very few reasons to
move from Perl to Python based on the feature list. People switch
because they want to get away from over-flexibility and concision.

"The syntax that had seemed merely eccentric at a hundred lines began to
seem like a nigh-impenetrable hedge of thorns at a thousand. ``More than
one way to do it'' lent flavor and expressiveness at a small scale, but
made it significantly harder to maintain consistent style across a wider
code base."

 *
http://local.eleceng.uct.ac.za/courses/EEE103W/python/www2.linuxjournal.com/lj-issues/issue73/3882.html

"For example, for those who don't continuously write Perl scripts, Perl
can be a "write only" language. That is, only the author of a Perl
script can understand it and even for the author understanding fades
over time."

 * http://www.bearcave.com/unix_hacks/python.html

"Of course, you can write beautiful, readable perl. As a high-level,
loosely typed languages, both perl and python skip the tedious level of
detail required by languages like C and Java, and let you jump right
into your actual code. ... Unfortunately, the people stuck with the job
of updating your code aren't perl interpreters, and the jargon gets in
the way. The more you take advantage of perl's expressive power, the
more mental energy it takes to understand it later."

Advantages of Perl: free, great support network, large existing codebase
Disadvantages: easy to get into bad habits, 'write-only ' code

 * http://www.dooyoo.co.uk/review/60523.html

So these are real testimonials. And Perl programmers will probably treat
them as Lisp programmers would complaints about parentheses, or Python
programmers would treat complaints about performance: "its all in your
head".

In one of your essays, you said that unifying expressions and statements
is great because you can put the assignment first in the conditional or
the conditional in the assignment. Python was designed (or at least
_adopted_) in repudiation of the philosophy that having two ways to say
the same thing is better than having a single way. If you really want to
understand why Python will never, ever, grow into Lisp, you should
consider this semi-whimisical list of Python design guidelines. I've
highlighted the most relevant ones.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
***Explicit is better than implicit.*** (e.g. don't mutate implicitly)
Simple is better than complex.
Complex is better than complicated.
***Flat is better than nested.***
***Sparse is better than dense.***
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
***There should be one-- and preferably only one --obvious way to do
it.***
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

(note that this last one does not mean namespaces in the Common Lisp
sense. Python puts functions, classes and assigned variables in the same
namespace)

> Incidentally, I am not a big fan of comments.  I think they
> are often an artifact of using weak languages.  I think
> that programming languages should be a good enough way to
> express programs that you don't have to scrawl additional
> clarifications on your source code.  It would be a bad
> sign, don't you think, if a novelist had to print notes
> in the margins saying "she left without saying anything
> because she was angry about the trampled petunias?"  It is
> the job of the novel to make that clear.  

No, it is the job of the novel to make that obscure so that it will be
perceived as deep. But anyhow....

> .... I think this is
> what SICP means when they say "programs must  be written
> for people to read, and only incidentally for  machines to
> execute."  I use comments mostly to apologize/warn about
> hacks, kludges, limitations, etc.

Sure. They can also be used for positive purposes: "I got this algorithm
here. I chose it rather than the other one because..." And let's not
forget docstrings.

 Paul Prescod