By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,767 Members | 1,995 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,767 IT Pros & Developers. It's quick & easy.

Zen of Python

P: n/a
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:

Flat is better than nested.

I strive for balance between flat and nested. Does anyone have a good
example of where this is applied? (specifically to python, or in
general)
Jul 18 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Timothy Fitz wrote:
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:

Flat is better than nested.

I strive for balance between flat and nested. Does anyone have a good
example of where this is applied? (specifically to python, or in
general)


Such sayings are deliberately somewhat ambiguous or simplified,
partly because they make one think a little more that way,
partly because the PSU places strict limits on how many characters
are allowed in Pythonic sayings. (Some PSU members are very small
and the output of "import this" didn't fit on their T-shirts without
this restriction.) (You never read this message. These are not
the droids you're looking for.)

Regardless, think of the meaning of "flat is better than nested"
as being in essence what you say you strive for. Comparing extremes
-- "completely flat is better than incredibly deeply nested" --
is sort of pointless. It seems likely, therefore, that nobody should
infer from this that completely "flat" is always better than any
amount of nesting, no matter how little.

And with that out of the way, one is left with "there's a balance
along the flat/nested dimension which is appropriate to any
given situation, so nest with moderation and only when necessary".

But that didn't fit in the list so they went with the shorter version...

-Peter
Jul 18 '05 #2

P: n/a
Peter Hansen wrote:
Timothy Fitz wrote:
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:

Flat is better than nested.
[incrdeibly secret PSU facts blurted out]
And with that out of the way, one is left with "there's a balance
along the flat/nested dimension which is appropriate to any
given situation, so nest with moderation and only when necessary".
They'd probably been talking to Antoon Pardon :-)
But that didn't fit in the list so they went with the shorter version...

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Jul 18 '05 #3

P: n/a

Timothy Fitz wrote:
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:

Flat is better than nested.

I strive for balance between flat and nested. Does anyone have a good
example of where this is applied? (specifically to python, or in
general)

I think the essence of why this Zen is true is the recognition that the
world isn't really organized into a nice, proper, perfect heirarchy,
where every node is a perfect little subset of its parent.

The fact is, some things are flat. A list is flat. Is is not better
to deal with flat things flatly?

And some things aren't flat, but they're not nested either. Rather,
they are various overlapping sets, but not subsets. It it better to
deal with such as mess by shoehorning it into a heirarchy that isn't
applicable, or to make it flat and deal with the subsets individually?

I shall give two examples of where Python exhibits this Zen, and doing
one my favorite things in the process: slamming other languages.
ITERATION

There are two ways to iterate: the flat way, with a for loop or list
comprehension or something like that; and the nested way, recursively.
We all know that recursion is often absolutely necessary. But usually
flat iteration suffices.

In other languages (notoriously LISP and functional languages), there
is a tendency to do it recursively anyways. For example, the following
Python code illustrates a recursive way to copy a list that would be
considered an example of "good code" in a language such as LISP:

.. def copylist(a):
.. if a: return a[:1] + copylist(a[1:])
.. else: return a

LISP, of course, was designed to make recursive processing like this
easy and efficient. But it doesn't, IMHO, keep recursion from being
much harder to figure out. Although this has a sort of coolness in
that you can see the list copy operation reduced to its simplest
possible form (in the same way that Game of Life is cool because you
get all kinds of complexity from very simple rules), it completely
misses the big picture. When I want to copy a list, I want to copy a
list; I don't want to figure out the minimal rule set I could use to do
it. Iteration fits the mind better.

Python, IMO, wisely put the focus on iteration.
POLYMORPHISM

In many languages, the only way to get dynamic polymorphism is to
subclass. If two classes are to share an interface, they have to both
be subclasses of a common base class. If you have lots of classes that
you want to share parts of their interfaces, you have to put them all
into that heirarchy.

The problem is, the world isn't a neatly organized tree, where every
type of object must have functionality that is an exact proper subset
of some other type of object. So what you end up with is this big,
messy, inflexible hierarchy of classes that is difficult to make
changes or add new options to. Many classes have stuff in them that
ought not to be there, just to satisfy the requirements of subclassing.
Oftentimes, the root class has lots of methods that many subclasses
don't implement. Oftentimes, there will be subclasses with
functionality that isn't polymorphic because the root class doesn't
define virtual methods for them.

(For an example of all this madness: in I/O hierarchies, the base class
often has seek() and tell() methods, but since not all streams are
seekable, it also has to have a seekable() method. Thus, polymorphic
behavior and its benefits are abandoned in favor of the procedural way.
Sure, for this case, you could just define a SeekableStream
intermediate class, only for seekable streams. But here's the thing:
there are any number of functionalities a stream may or may not have.
Are you going to design a hierarchy with branches to account for all
possible combinations of them?)

Not so in Python. In Python, if you want to classes to have the same
interface, then write two classes that have the same methods. Bam, you
got polymorphism. No shoehorning into a heirarchy necessary. It's
what we call duck typing. (If it looks like a duck, and floats like a
duck, it's made of wood.)

The flat method of polymorphism is so much better it isn't even funny.
Again, Python chose wisely.
--
CARL BANKS

Jul 18 '05 #4

P: n/a
On Wed, 19 Jan 2005 14:13:47 -0500, Timothy Fitz <fi******@gmail.com>
wrote:
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:

(snip)

For those interested, here's the list:

http://www.python.org/doc/Humor.html#zen

Luke.
Jul 18 '05 #5

P: n/a
Luke Skywalker <lu**@tatooine.planet> schreef:
On Wed, 19 Jan 2005 14:13:47 -0500, Timothy Fitz
While I agree that the Zen of Python is an amazingly concise list
of truisms, I do not see any meaning in:


For those interested, here's the list:
http://www.python.org/doc/Humor.html#zen


Or you just type at the interactive prompt:
import this


Regards,
Jan

Jul 18 '05 #6

P: n/a
Op 2005-01-19, Steve Holden schreef <st***@holdenweb.com>:
Peter Hansen wrote:
Timothy Fitz wrote:
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:

Flat is better than nested.

[incrdeibly secret PSU facts blurted out]

And with that out of the way, one is left with "there's a balance
along the flat/nested dimension which is appropriate to any
given situation, so nest with moderation and only when necessary".

They'd probably been talking to Antoon Pardon :-)


Just what I thought: They'll be accusing me of this :-)

--
Antoon Pardon
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.