Why "flat is better than nested"?
steve-REMOVE-THIS at cybersource.com.au
Thu Oct 28 03:40:45 CEST 2010
On Wed, 27 Oct 2010 14:02:27 +0000, kj wrote:
> I have nothing against humor. The reason why I find "import braces"
> funny is that it is so obviously a joke. But I do find it mildly
> annoying (and just mildly) that a joke/hoax/farce like ZoP/this.py is
> built into the standard lib, because a lot of people (not just me) don't
> realize it's a joke.
What makes you think it's a joke?
> I don't see the point
> of making the task any harder than it already is by injecting additional
> *gratuitous confusion* in the form pseudo-rogramming advice that
> apparently no experienced Python program really believes/takes seriously
You're badly misinformed if you think that Python programmers don't take
the Zen seriously.
I dare say some don't, particularly those who like writing Lisp/Java/PHP/
whatever in Python. I also expect that some take it *too* seriously, as
Although the Zen is written in a light-hearted fashion, it is not
intended as a joke. Every line in the Zen is genuine advice -- even the
one about being Dutch. Would it help to write it out in a less light-
When programming in Python, you should:
Aspire to write beautiful, elegant code and algorithms, rather than ugly
Programming is about giving instructions to the computer. It is better to
give those instructions explicitly, rather than implicitly based on the
context -- context which may not be quite what you expect, or that the
reader may not have recognized.
Simple code has fewer things to go wrong, less to understand, and fewer
places for bugs to hide. Prefer simple code to complex code.
Complex problems may require complex solutions. But complicated solutions
should be avoided if you can. A watch is complex; the rules of precedence
and etiquette in the court of Louis the Sun King in 17th century France
Flat data structures are typically easier and faster to parse, and should
be preferred over nested data structures. Where you need nested data
structures, prefer shallow rather than deeply nested.
You read source code much more often than you write it, and consequently
readability of the code is important. Aim to maximize readability unless
performance dictates compromising on readability.
Languages and libraries should aim for consistency and should support the
general case. Resist the temptation to pile on support for special cases
that are useless for nearly everybody. Let the caller handle their own
special cases in their code.
Unless there are good, practical reasons for supporting a special case.
Errors should be treated as errors. Library code should always report
errors that occur, and not just silently suppress them.
Users should have the option to explicitly silence errors they don't care
If a situation is ambiguous, functions should not try to guess what the
caller meant. They will sooner or later get it wrong.
For each task the user wants to do, there should be an obvious way to do
it. Preferably only one obvious way, but multiple solutions are allowed.
If there is no obvious way at all, then the language or library is
Sometimes what is obvious to Python's designer, Guido van Rossum, who is
Dutch, may not be obvious to anyone else who doesn't share his
background. Live with it.
If something needs doing, it is better to do it now than to procrastinate
and never get it done. Don't wait for software to be perfect -- you can
measure many things with a ruler with a notch in the side, and even a
blunt saw cuts better than no saw at all.
But sometimes it is better to do without than to lock yourself into a
faulty standard. If there's no solution that's good enough right now, it
may be better to wait for one than to be stuck forever on a bad solution.
If the implementation of software is complicated and hard to explain how
it works, it is probably a mistake to go down that path. Find a better
If the implementation is simple and easy to explain, it may be a good
idea. But some ideas are just bad, regardless of whether they are easy to
implement or not.
Namespaces are a tried and tested solution to many programming jobs. We
should use them more often in Python.
535 words instead of 137. I prefer the Zen.
You'll note that some of the maxims are general rather than specific to
Python. Some might argue that *all* the maxims are perfectly general, and
the fact that other languages make other choices is their loss.
More information about the Python-list