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.des...@gmail.com
> On Oct 25, 11:07 am, kj <no.em...@please.post> wrote:
>
> > 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.
>
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.
--
Robin Becker
Alex Willmer
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
kj
>On Oct 25, 5:07=A0am, kj <no.em...@please.post> wrote:
>> In "The Zen of Python", one of the "maxims" is "flat is better than
>> nested"? =A0Why? =A0Can anyone give me a concrete example that illustrate=
>s
>> 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!
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
> On Oct 25, 5:07 am, kj <no.em...@please.post> wrote:
>> 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?
>
> 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!
>
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 +1 571 484 6266 +1 800 494 3119
PyCon 2011 Atlanta March 9-17 http://us.pycon.org/
See Python Video! http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/
Steve Holden
>> nested"? Why? Can anyone give me a concrete example that illustrates
>> this point?
>
kj
>On 10/25/2010 10:47 AM, rantingrick wrote:
>> On Oct 25, 5:07 am, kj <no.em...@please.post> wrote:
>>> 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!
>>
>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
Steve Holden
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.
Ethan Furman
> In <mailman.232.1288020...@python.org> Steve Holden <st...@holdenweb.com> writes:
>
>>> On Oct 25, 5:07 am, kj <no.em...@please.post> wrote:
>>>> 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?
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.
>> 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.
The Zen is good humor, and good advice. An excellent reminder to strive
for balance in all things...
~Ethan~
--
* citation needed, I know
Ben Finney
> 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 ...
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.
--
\ “Dyslexia means never having to say that you're ysror.” |
`\ —anonymous |
_o__) |
Ben Finney
Jorgen Grahn
Which mainstream languages are you thinking of? Java? Because C++ is
as flat as Python.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Carl Banks
> On Mon, 2010-10-25, bruno.desthuilli...@gmail.com wrote:
> > On 25 oct, 15:34, Alex Willmer <a...@moreati.org.uk> wrote:
> >> On Oct 25, 11:07 am, kj <no.em...@please.post> wrote:
>
> >> > 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.
>
> > (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.
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:
>> Well, it's pretty *enshrined*, wouldn't you say?
>No.
> > After all, it is part of the standard distribution,
>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 darwin
>>> import antigravity
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named antigravity
Too bad, I was looking forward to that.
> > 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).
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
> In <mailman.241.1288036...@python.org> Terry Reedy <tjr...@udel.edu> writes:
>
>>On 10/25/2010 3:11 PM, kj wrote:
>
>>> Well, it's pretty *enshrined*, wouldn't you say?
>
>>No.
>
>> > After all, it is part of the standard distribution,
>
>>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 darwin
>>>> import antigravity
> Traceback (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.
>> > 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).
>
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
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.)
>
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 ;-)
Robin Becker
> he answer is probably the same as you will see if you try
>
> from __future__ import braces
>
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
John Nagle
> On Oct 25, 11:07 am, kj<no.em...@please.post> wrote:
>> 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
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
My favorite is always:
from django.contrib.auth.models import User # I know, not std lib
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
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.
I don't want spam, spam, spam, python and spam in my inbox. :)
Ian
Steve Holden
Jorgen Grahn
> On Oct 25, 11:20�pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Mon, 2010-10-25, bruno.desthuilli...@gmail.com wrote:
>> > On 25 oct, 15:34, Alex Willmer <a...@moreati.org.uk> wrote:
>> >> On Oct 25, 11:07�am, kj <no.em...@please.post> wrote:
>>
>> >> > 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.
>>
>> > (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.
>
> 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::product::subsystem::...
Stefan Behnel
> "I know that that that that that boy said is wrong!".
What's a "that boy"?
Stefan
Robin Becker
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
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
>On 10/26/2010 2:44 PM, kj wrote:
>> In <mailman.258.1288104...@python.org> Steve Holden <st...@holdenweb.com> writes:
>>
>>> 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.
>>
>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.
nn
> kj wrote:
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
Steven D'Aprano
> Steve Holden <st...@holdenweb.com> writes:
>
>> 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 ...
>
> 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.
--
Steven
alex23
> > Load the source code for the ‘this’ module into a text editor, and see
> > how many of the maxims it violates.
>
> 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
> >> "I know that that that that that boy said is wrong!".
>
>
> 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
> On 27/10/2010 10:13, Stefan Behnel wrote:
>> Robin Becker, 25.10.2010 15:56:
>>>
>>
>>
How about this breakdown:
I know that that "that", that that boy said, is wrong !
Steven D'Aprano
> Steven D'Aprano <steve-REMOVE-T...@cybersource.com.au> wrote:
>> > Load the source code for the ‘this’ module into a text editor, and
>> > see how many of the maxims it violates.
>>
>> None of them.
>
> 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!
--
Steven
Ben Finney
> On Wed, 27 Oct 2010 22:45:21 -0700, alex23 wrote:
> > 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.
Yes, and to that end it's also (deliberately, in my view) breaking as
many of the Zen admonishments as it can.
That was my point.
--
\ “To save the world requires faith and courage: faith in reason, |
`\ and courage to proclaim what reason shows to be true.” |
_o__) —Bertrand Russell |
Ben Finney
Andreas Waldenburger
wrote:
No, it wouldn't, hence Stefan's (and your) error. It maps to a specific
boy. Replacing "that"s where possible, it becomes:
I know that [the] "that" [which] that boy said is wrong.
/W
--
To reach me via email, replace INVALID with the country code of my home
country. But if you spam me, I'll be one sour Kraut.
alex23
> No, it wouldn't, hence Stefan's (and your) error. It maps to a specific
> boy. Replacing "that"s where possible, it becomes:
>
> I know that [the] "that" [which] that boy said is wrong.
Ah, I see now: I know that that "that" that _that_ boy said is wrong :)
Lawrence D'Oliveiro
Behnel wrote:
> What's a "that boy"?
A boy who’s the opposite of fin.
J. Gerlach
> [ snip a lot of wise words ]
Can I put this (translated) in the german python wiki?
I guess it might help more people to understand some decisions taken
during python's development - and I'm to lazy to do something similar
myself ;)
Greetings from Berlin
Jörg Gerlach
Steven D'Aprano
> Am 28.10.2010 03:40, schrieb Steven D'Aprano:
>> [ snip a lot of wise words ]
>
> Can I put this (translated) in the german python wiki? I guess it might
> help more people to understand some decisions taken during python's
> development - and I'm to lazy to do something similar myself ;)
Sure, go ahead.
I would appreciate a link back to my post, and/or credit, but that's not
essential. (I understand it's a wiki and there's no guarantee that the
link will remain there forever.)
--
Steven
rustom
> In <mailman.232.1288020268.2218.python-l...@python.org> Steve Holden <st...@holdenweb.com> writes:
>
>
>
> >>> 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?
>
> >> 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!
>
> >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 ...
>
> 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.
>
If you take zen seriously you dont get it
If you dont take zen seriously you dont get it
That -- seriously -- is zen
Peter Otten
> If you take zen seriously you dont get it
> If you dont take zen seriously you dont get it
You forgot:
If you explain zen you don't get it
J. Gerlach
via googlegroups.
rustom
I guess different communities have different settings for 'explanation-
toleration' (as also 'seriousness')
eg. Classical zen: If you the Buddha on the road kill him!
Now :s/the Buddha/Jesus Christ/ and it suddenly seems more offensive
-- not because the Buddha and Jesus Christ are all that different but
because the respective communities have different seriousness
defaults.
And as for another teacher whose sphere of influence was a few hundred
km from Jesus' I am going to be even more careful because the
seriousness-defaults are set lower still...
Lawrence D'Oliveiro
<d4e7f8b9-9526-4bf5...@b19g2000prj.googlegroups.com>, rustom
wrote:
> If you take zen seriously you dont get it
> If you dont take zen seriously you dont get it
> That -- seriously -- is zen
I don’t get it.
Rustom Mody
If you take zen seriously you dont get it
Gregory Ewing
I get it. Does that mean that I don't get it?
--
Greg
John Posner
>>
>> I don’t get it.
>
> I get it. Does that mean that I don't get it?
Yes. As Dr. Feynman said about quantum mechanics.
-John
alex23
> I get it. Does that mean that I don't get it?
Mu.
andrew...@gmail.com
> 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?
>
>
> ~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".
I think there is a point where flat stops working. One of the products I work on has a 40-50 field datastructure - it is hard to work with and find the appropriate fields in. So I would say structured is better than flat but simple is better than to structured.
Steve D'Aprano
In any case, structured is not the opposite of flat. Nested is the opposite to
flat, and unstructured is the opposite of structured. The two concepts are
independent of each other: any data structure can be:
- flat and structured;
- flat and unstructured;
- nested and structured;
- nested and unstructured.
Data can even be semi-structured; for example, mp3 files have some structured
metadata (title, artist, track number, comment, etc), while data in the
comment field itself is unstructured (free-form) text.
Here is an example of iterating over a flat collection of numbers:
values = [1, 2, 3, 4, 5, 6, 7, 8]
for num in values:
print(num)
Here is the same, as a nested collection of numbers:
values = [1, [2, [3, [4, [5, [6, [7, [8, []]]]]]]]]
while values:
num, values = values
print(num)
In Python, the first is much more efficient than the second. It is also easier
to write, easier to read, and less likely for the programmer to mess up.
A list or a dict is flat; a binary tree is nested.
Structured and unstructured data can have two related but separate meanings.
One is to distinguish between data with or without a pre-defined
organization:
- structured data: XML, JSON, YAML, databases, etc;
- unstructured data: books, the body of emails, arbitrary web pages, etc.
Dealing with unstructured data in this sense often means coming up with some
sort of heuristic or "best guess" for picking out the useful information
(say, based on regexes) then writing a scraper to pull part the data source
looking for what you want.
The meaning you seem to be using seems to be:
- structured data has named fields (e.g. C struct, Pascal record,
object with named attributes, Python named tuple, CSV file with
descriptive column headers);
- unstructured data does not name the fields (e.g. a plain tuple,
CSV file without column headers) and you have to infer the
meaning of each field from out-of-band knowledge (say, you read
the documentation to find out that "column 7" is the score).
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
Lawrence D’Oliveiro
> I think there is a point where flat stops working.