Why "flat is better than nested"?

[kj]

In "The Zen of Python", one of the "maxims" is "flat is better than
nested"? Why? Can anyone give me a concrete example that illustrates
this point?

TIA!

~kj

PS: My question should not be construed as a defense for "nested".
I have no particular preference for either flat or nested; it all
depends on the situation; I would have asked the same question if
the maxim had been "nested is better than flat".

 

[Alex Willmer]

In "The Zen of Python", one of the "maxims" is "flat is better than
nested"?  Why?  Can anyone give me a concrete example that illustrates
this point?

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

import org.example.thirdparty.something

There are of course some Python packages that go deeper than 2
(xml.dom.minidom), but the majority are shallow. I think the
motivation is to make the packages more discoverable, and to avoid
classification arguments (does regex go under util or text). Alone the
statement would imply a single, global space ala C but that of course
is evil and so one must balance it with "Namespaces are one honking
great idea -- let's do more of those!"

I don't think it applies to data structures though. If a deeply nested
tree models your data well, then use it.

Regards, Alex

 

[bruno.desthuilliers]

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.

(snip)

This also applies to inheritance hierarchies (which tend to be rather
flat in Python compared to most mainstreams OOPLs), as well as nested
classes etc.

 

[Robin Becker]

In "The Zen of Python", one of the "maxims" is "flat is better than
nested"? Why? Can anyone give me a concrete example that illustrates
this point?

........
I believe that the following illustrates the nesting issue (I think this is from
somewhere in Chomsky)


The rat ate the corn.
The rat that the cat killed ate the corn.
The rat that the cat that the dog chased killed ate the corn.

I believe this is called central embedding.


There's also the old schoolboy saying "I know that that that that that boy said
is wrong!".

The nested nature makes the semantics quite hard. The same will be true of
nested tuple/list and similar programming structures.

 

[Alex Willmer]

.......
I believe that the following illustrates the nesting issue (I think this is from
somewhere in Chomsky)

The rat ate the corn.
The rat that the cat killed ate the corn.
The rat that the cat that the dog chased killed ate the corn.

I believe this is called central embedding.

There's also the old schoolboy saying "I know that that that that that boy said
is wrong!".

The nested nature makes the semantics quite hard. The same will be true of
nested tuple/list and similar programming structures.

I agree in the case of a suped-up hierachical record structure that
encourages code like

my_far =
the_record.something.something_else.foo[2].keep_going.bar.baz()

A tree of homogeneous nodes that one walks or recurses into (e.g. a b-
tree or r-tree) is a case where I would ignore this maxim

 

[rantingrick]

In "The Zen of Python", one of the "maxims" is "flat is better than
nested"?  Why?  Can anyone give me a concrete example that illustrates
this point?

Simple. This commandment (endowed by the anointed one, GvR) is
directed directly at lisp and those filthy lispers. If you don't know
what lisp is then Google it. Then try to program with it for one hour.
Very soon after your head will explode from the nested bracket plague
and then you shall be enlightened!

 

[kj]

Simple. This commandment (endowed by the anointed one, GvR) is
directed directly at lisp and those filthy lispers. If you don't know
what lisp is then Google it. Then try to program with it for one hour.
Very soon after your head will explode from the nested bracket plague
and then you shall be enlightened!

Some of the earliest programming I ever did was in Lisp. Scheme
actually. In good ol' 6.001, back in '82. I loved it. I have no
problem whatsoever with it.

Benightedly yours,

~kj

 

[Steve Holden]

Simple. This commandment (endowed by the anointed one, GvR) is
directed directly at lisp and those filthy lispers. If you don't know
what lisp is then Google it. Then try to program with it for one hour.
Very soon after your head will explode from the nested bracket plague
and then you shall be enlightened!

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

regards
Steve

 

[Steve Holden]

Simple. This commandment (endowed by the anointed one, GvR) is
directed directly at lisp and those filthy lispers. If you don't know
what lisp is then Google it. Then try to program with it for one hour.
Very soon after your head will explode from the nested bracket plague
and then you shall be enlightened!

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

regards
Steve

 

[kj]

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

Well, it's pretty *enshrined*, wouldn't you say? After all, it is
part of the standard distribution, has an easy-to-remember invocation,
etc. *Someone* must have taken it seriously enough to go through
all this bother. If it is as trivial as you suggest (and for all
I know you're absolutely right), then let's knock it off its pedestal
once and for all, and remove it from the standard distribution.

~kj

 

[Terry Reedy]

Well, it's pretty *enshrined*, wouldn't you say?
No.

> After all, it is part of the standard distribution,

So is 'import antigravity'

> has an easy-to-remember invocation,
etc. *Someone* must have taken it seriously enough to go through
all this bother. If it is as trivial as you suggest (and for all
I know you're absolutely right), then let's knock it off its pedestal
once and for all, and remove it from the standard distribution.

If you are being serious, you are being too serious (as in humorless).
The 'Zen of Python' is somewhere between 'trivial' and 'enshrined on a
pedestal'. The two undocumented easter egg imports (visible in
pythonx.y/Lib) are for both fun and edification.

 

[Steve Holden]

Well, it's pretty *enshrined*, wouldn't you say? After all, it is
part of the standard distribution, has an easy-to-remember invocation,
etc. *Someone* must have taken it seriously enough to go through
all this bother. If it is as trivial as you suggest (and for all
I know you're absolutely right), then let's knock it off its pedestal
once and for all, and remove it from the standard distribution.

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.

Besides which I am sure Tim Peters derives a lot of harmless fun from
seeing people take it so seriously.

regards
Steve

 

[Ethan Furman]

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.

Well, it's pretty *enshrined*, wouldn't you say? After all, it is
part of the standard distribution, has an easy-to-remember invocation,
etc. *Someone* must have taken it seriously enough to go through
all this bother. If it is as trivial as you suggest (and for all
I know you're absolutely right), then let's knock it off its pedestal
once and for all, and remove it from the standard distribution.

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

~Ethan~

 

[Jorgen Grahn]

(snip)

This also applies to inheritance hierarchies (which tend to be rather
flat in Python compared to most mainstreams OOPLs), as well as nested
classes etc.

Which mainstream languages are you thinking of? Java? Because C++ is
as flat as Python.

/Jorgen

 

[Carl Banks]

Which mainstream languages are you thinking of?  Java?  Because C++ is
as flat as Python.

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


Carl Banks

 

[kj]

On 10/25/2010 3:11 PM, kj wrote:

So is 'import antigravity'

Are you playing with my feelings?

% python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwinTraceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named antigravity

Too bad, I was looking forward to that.

If you are being serious, you are being too serious (as in humorless).

Guilty as charged, both in the "too serious" and the "humorless"
counts. :/ Blame it on the Asperger's.

My only defense is that, while learning Python over the past year,
I've had *many* "you've got to be joking" moments while reading
what's ostensible "serious" Python documents (e.g. PEP 8, PEP 257)
as well as assorted threads featuring GvR and others involved in
the design of Python, to the point that sometimes I do have a hard
time gauging the seriousness of what's considered "good programming"
/ "best practice" in the Python world.

Plus, I think it's fair to say that the Python community as a whole
(or at least its more vocal members) are more concerned with
"correctness" (for lack of a better term) and "code aesthetics"
than, say, the Perl community. E.g., only in Python-related threads
I've seen the adjective "icky" used routinely to indicate that some
code is unacceptable on (more or less) aesthetic grounds.

My point is that, even if one detects some levity in ZoP, given
everything else one runs into in the Python world, for the uninitiated
like me it is still hard to distinguish between what's in jest and
what's in earnest.

Perhaps the disconnect here is that you're seeing the whole thing
from an insider's point of view, while I'm still enough of an
outsider not to share this point of view. (I happen to think that
one the hallmarks of being an initiate to a discipline is an almost
complete loss of any memory of what that discipline looked like
when the person was a complete novice. If this is true, then it's
easy to understand the difference in our perceptions.)

Anyway, thanks for letting me in on the joke. I'll pass it on.

(Though, humorless as it is of me, I still would prefer the ZoP
out of the standard library, to save myself having to tell those
who are even newer to Python than me not to take it seriously.)

~kj

 

[Benjamin Kaplan]

On 10/25/2010 3:11 PM, kj wrote:

So is 'import antigravity'

Are you playing with my feelings?

% python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwinTraceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: No module named antigravity

Too bad, I was looking forward to that.

Try it in Python 3.

Guilty as charged, both in the "too serious" and the "humorless"
counts. :/  Blame it on the Asperger's.

My only defense is that, while learning Python over the past year,
I've had *many* "you've got to be joking" moments while reading
what's ostensible "serious" Python documents (e.g. PEP 8, PEP 257)
as well as assorted threads featuring GvR and others involved in
the design of Python, to the point that sometimes I do have a hard
time gauging the seriousness of what's considered "good programming"
/ "best practice" in the Python world.

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.

 

[Seebs]

(Though, humorless as it is of me, I still would prefer the ZoP
out of the standard library, to save myself having to tell those
who are even newer to Python than me not to take it seriously.)

Well, not to take it *too* seriously.

It's like any other Zen -- it's wonderful as long as you take it about
the right amount seriously. If someone could tell you how seriously
that is, it wouldn't be Zen.

-s

 

[Steve Holden]

Perhaps the disconnect here is that you're seeing the whole thing
from an insider's point of view, while I'm still enough of an
outsider not to share this point of view. (I happen to think that
one the hallmarks of being an initiate to a discipline is an almost
complete loss of any memory of what that discipline looked like
when the person was a complete novice. If this is true, then it's
easy to understand the difference in our perceptions.)

That can be true of most technical communities, and Python is no
exception. As someone who does quite a lot of training the challenge is
always to hold on to those outsider perceptions to avoid the learners
feeling lost.

Anyway, thanks for letting me in on the joke. I'll pass it on.

(Though, humorless as it is of me, I still would prefer the ZoP
out of the standard library, to save myself having to tell those
who are even newer to Python than me not to take it seriously.)

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

regards
Steve

 

[Robin Becker]

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

from __future__ import braces

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

In the past I used to think it was really cool that one could do

from __future__ import exciting_and_cool_new_stuff


now I really wish we had

from __past__ import old_and_boring_syntax_26

etc etc
-trapped on level five-ly yrs-
Robin Becker