Why "flat is better than nested"?

[John Nagle]

I take this as a reference to the layout of the Python standard
library and other packages i.e. it's better to have a module hierarchy
of depth 1 or 2 and many top level items, than a depth of 5+ and only
a few top level items.

For instance

import re2
import sqlite3
import logging

import something_thirdparty

vs

import java.util.regex
import java.sql
import java.util.logging

As in

Python 2: import urllib
Python 3: import urllib.request, urllib.parse, urllib.error

http://diveintopython3.org/porting-code-to-python-3-with-2to3.html

John Nagle

 

[Albert Hopkins]

As in

Python 2: import urllib
Python 3: import urllib.request, urllib.parse, urllib.error

http://diveintopython3.org/porting-code-to-python-3-with-2to3.html

My favorite is always:

from django.contrib.auth.models import User # I know, not std lib

 

[Ian]

This is a programming language named after a British comedy group (not
the snake). There are going to be jokes inserted in lots of otherwise
serious things. Like the standard library.

Please, lets NOT get a newsgroup cross feed!

I don't want spam, spam, spam, python and spam in my inbox.

Ian

 

[kj]

The answer is probably the same as you will see if you try

from __future__ import braces

That feature *is* available in Python 2.6 ;-)

Now, that's hilarious.

kj

 

[Steve Holden]

Now, that's hilarious.

See, there *is* a place for humor

regards
Steve

 

[Jorgen Grahn]

Not in my experience. The only way to get dynamic polymorphism (as
opposed to the static polymorphism you get with templates) in C++ is
to use inheritance, so when you have a class library in C++ you tend
to get hierarchies where classes with all kinds of abstract base
classes so that types can be polymorphic.

I should have mentioned that I talked about the standard C++ library:
almost no inheritance[1] and just one namespace level.

Of course you can make a layered mess of C++ if you really try[2], but
it's not something the language encourages. IMHO.

In Python you don't need
abstract base classes so libraries tend to be flatter, only inheriting
when behavior is shared.

However it's not really that big of a difference.

Right, that's one level, and you can't avoid it if you really *do* need
inheritance.

/Jorgen

[1] Not counting the black sheep, iostreams.
[2] I have seen serious C++ code trying to mimic the Java bottomless
namespace pit of despair: com::company::division:roduct::subsystem::...

 

[Stefan Behnel]

Robin Becker, 25.10.2010 15:56:

"I know that that that that that boy said is wrong!".

What's a "that boy"?

Stefan

 

[Robin Becker]

Robin Becker, 25.10.2010 15:56:

What's a "that boy"?

Stefan

well they say nested is hard. How about this break down


I know that X that a boy said is wrong. (any boy)
I know that X that the boy said is wrong. (a single boy)
I know that X that that boy said is wrong. (a specific boy)

now what could we substitute for X? eg "a Y", "the Y" or "that Y". Now I wonder
what Y could be eg "word" "utterance" "that".

Any way a "that boy" is a specific boy and a "that that" is a specific that etc
etc mumble mumble
-dementedly yrs-
Robin Becker

 

[Lie Ryan]

I don't know who decided to put the "this" module into Python as an
Easter egg. But don't think you can suppress it now. Trying to do so
would only bring out people's inherent religious fervor and cause an
outcry you would regret.

Now you know who to blame (assuming mercurial log is not lying

$ hg blame this.py
21335: s = """Gur Mra bs Clguba, ol Gvz Crgref
21337:
21335: Ornhgvshy vf orggre guna htyl.
21335: Rkcyvpvg vf orggre guna vzcyvpvg.
21335: Fvzcyr vf orggre guna pbzcyrk.
21335: Pbzcyrk vf orggre guna pbzcyvpngrq.
21335: Syng vf orggre guna arfgrq.
21335: Fcnefr vf orggre guna qrafr.
21335: Ernqnovyvgl pbhagf.
21335: Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
21335: Nygubhtu cenpgvpnyvgl orngf chevgl.
21335: Reebef fubhyq arire cnff fvyragyl.
21335: Hayrff rkcyvpvgyl fvyraprq.
21335: Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
21335: Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
21335: Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
21335: Abj vf orggre guna arire.
21335: Nygubhtu arire vf bsgra orggre guna *evtug* abj.
21335: Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
21335: Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
21335: Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""
21337:
29075: d = {}
29075: for c in (65, 97):
29075: for i in range(26):
29075: d[chr(i+c)] = chr((i+13) % 26 + c)
29075:
29075: print "".join([d.get(c, c) for c in s])

$ hg log -r 21335 this.py
changeset: 21335:56190cb9ccb6
branch: trunk
user: fdrake
date: Fri Feb 08 21:13:47 2002 +0100
summary: [svn r25249] Python 10 was a success, commemorate it\!

 

[kj]

See, there *is* a place for humor

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. (In fact, the reason I learned
about ZoP/this.py was that in a reply to some post of mine in some
Python forum [maybe c.l.py], the responder simply told me to run
"import this", with the implication that it would answer whatever
it was that I was asking about. Either this person took ZoP
seriously, or was just having fun at a noob's expense. Either way,
I don't like it.) Learning a new programming language (which
entails becoming familiar not only with some new syntax, but new
libraries, new general ideas, new ways of doing stuff), is already
disorienting enough as it is. 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 anyway.
I just don't understand the need of having this.py in the std lib
of all places. It's not like there's any risk of losing the ZoP
if it were removed from it. Zillions of copies of it would be
floating around in the web. But it would not be confused as
something that is somehow endorsed by those who put together the
distribution.

I know. Not a chance.

~kj

 

[Seebs]

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.

It's not a joke. It's silly. That's different.

disorienting enough as it is. 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 anyway.

There's a world of difference between "take it seriously" and "adhere
to it with rigid dogmatism".

It's good advice, but like most style rules, they're not absolute rules
you should always follow no matter what.

So, yes, it's endorsed. As what it is, which is a set of tools for thinking
about Python, not as a set of formal dogmas to which all programs must adhere
or face excommunication.

-s

 

[nn]

Two points on the practical side:  most folk only remember a few levels
deep, so shallow is easier to work with*; and, while premature
optimization is usually a waste of time, effort, money, hair, etc., each
level costs another lookup.



The Zen is good humor, and good advice.  An excellent reminder to strive
for balance in all things...

~Ethan~

I think the ZoP is just another case of HHOS:
http://sunsite.ualberta.ca/jargon/html/H/ha-ha-only-serious.html

 

[Raymond Hettinger]

And everyone taking the Zen too seriously should remember that it was
written by Tim Peters one night during the commercial breaks between
rounds of wrestling on television. So while it can give useful guidance,
it's nether prescriptive nor a bible ...

This is Tim we're talking about. I would put his work during
commercial breaks against most programmer's work during
uninterrupted full days at the office. He probably created
the Timsort routine while playing Farmville in another window


Raymond

 

[Steven D'Aprano]

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

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

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



When programming in Python, you should:

Aspire to write beautiful, elegant code and algorithms, rather than ugly
and messy.

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

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

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

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

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.

 

[Steven D'Aprano]

Even to those who don't know or don't remember its history, the Zen has
an excellent reminder of just how seriously it should be taken:

Load the source code for the ‘this’ module into a text editor, and see
how many of the maxims it violates.

None of them. It's a straightforward implementation of rot13, but written
as a one-off script rather than a re-usable function. That's okay -- not
everything has to be re-usable.

The worst sin of this.py is something which is not mentioned in the Zen:
the use of magic constants rather than named values, and the use of ints
instead of characters. But as sins go, they're venal rather than mortal
in a module this small, and I interpret this as a deliberate: it's a
reminder that the Zen is not the last word in programming maxims.

 

[alex23]

None of them.

I'd say it easily violates the first 3, being neither beautiful,
explicit nor simple, and especially "Readability counts".

The whole thing could be replaced by a single print """The Zen
of...""". Arguing that re-implementing rot13 somehow doesn't go
against the grain of the Zen itself just seems odd.

 

[alex23]

well they say nested is hard. How about this break down

I know that X that a boy said is wrong. (any boy)
I know that X that the boy said is wrong. (a single boy)
I know that X that that boy said is wrong. (a specific boy)

But your original statement maps out to:

I know that X that that that boy said is wrong.

So this would apply to a specific 'that boy', hence Stefan's
question

 

[David]

well they say nested is hard. How about this break down

[...]

How about this breakdown:

I know that that "that", that that boy said, is wrong !

 

[Steven D'Aprano]

I'd say it easily violates the first 3, being neither beautiful,
explicit nor simple, and especially "Readability counts".

Well, beauty is in the eye of the beholder. Ignore the large,
unattractive rot13ed string literal -- nothing will ever make that
attractive. Or imagine it was a single line. That leaves a simple,
minimalist script:


s = "Clguba"

d = {}
for c in (65, 97):
for i in range(26):
d[chr(i+c)] = chr((i+13) % 26 + c)

print "".join([d.get(c, c) for c in s])


How is that not a thing of beauty? Oh sure, these days you could simply
write

print s.encode('rot13')

and you'd be done, but 'this.py' dates back to Python 2.1 when the rot13
encoding didn't exist.

I suppose one might change the magic constants 65, 97 to chr('A') and
chr('a'), or iterate over string.letters, but I already mentioned them.
As obfuscated code goes, it's about as obfuscated as rot13 applied twice,
and that's the beauty of it.

You say it's not explicit, but where is the implicitness? Is "print
<expr>" not explicit enough for you?

Simple? I'd like to see somebody write it more simply, other than using
the rot13 encoding (which didn't exist when the module was created).

I'm not trying to say that module 'this.py' should be held up as the
paragon of Python modules. It's more of a script than a true module,
which makes importing it for its side-effects (the print statement)
somewhat unusual. But violate the Zen? Hardly.

The whole thing could be replaced by a single print """The Zen of...""".

But that would miss the point. It's supposed to be light-hearted. Zen is
supposed to be a Mystery (with a capital M). You can't just stumble
across the Zen while grepping the source code. You have to make a
concerted effort to discover it with import this.

But we're over-analysing this. The message in the Zen is serious, but the
medium -- the silly obfuscation, the fake mysticism, the use of koan-like
form -- is light-hearted. It's not a web server, for heaven's sake, it
has five lines of code!

 

[rantingrick]

it was
written by Tim Peters one night during the commercial breaks between
rounds of wrestling on television.

Tim Peters...a "WrestleMania" fan...who would have guessed?

;-)