The Zen of Python (by example)

http://artifex.org/~hblanks/talks/2011/pep20_by_example.html

by saurabh • 14 years ago

133 25 14 years ago

Troll bait for Pythonistas. At least I hope that's what that is, because this needs some serious zen-ification otherwise.

To summarize, while switching religions: "The Tao that can be expressed is not the eternal Tao".

But if you're going to try to express the Zen of Python, you can do a hell of a lot better than this.

jacobolus• 14 years ago

Indeed. Half of it seems to be bashing popular libraries the author doesn’t like, and the other half is a mixture of extremely contrived examples, and examples that miss the point of whatever particular part of the Zen they’re supposed to illustrate.

cysun• 14 years ago

I thought I was missing something. I sure feel better about myself now.

alexatkeplar• 14 years ago

In #3, SQLAlchemy loses because it's "complex" while JSON is "simple". In #4, SQLAlchemy loses because this time it's "complicated", whereas inlining SQL create table statements is merely "complex".

Conclusion: for Hunter Blanks, SQLAlchemy can never win.

dchest• 14 years ago

"The order of examples is not necessarily bad first, good second." http://news.ycombinator.com/item?id=2203101

jobeirne• 14 years ago

IMO, #3 was more about YAGNI[1], i.e. you probably won't need the speed, integrity constraints, relations, etc. delivered by SQL, so keep your data model flexible and lightweight until a shortage of those things is actually getting in your way.

I wouldn't be surprised if many people criticizing #3 had no practical experience with NoSQL and the benefits brought by its lack of baggage.

[1] http://en.wikipedia.org/wiki/You_aint_gonna_need_it

glassx• 14 years ago

SQLAlchemy is "complex" in both #3 and #4, so it wins in #4.

pjo• 14 years ago

Previous discussion on HN: http://news.ycombinator.com/item?id=2203101

xerula• 14 years ago

Even as a fledgling Python coder, I found this distinctly unenlightening. But, as a biologist, the part that really bugged me were the functions that regard yeast as invertebrate animals.

ramanujan• 14 years ago

The "identify this animal" example has a serious bug. This:

  def identify(animal):
      if animal.is_vertebrate():
          return identify_vertebrate()
      else:
          return identify_invertebrate()

should be

  def identify(animal):
      if animal.is_vertebrate():
          return identify_vertebrate(animal)
      else:
          return identify_invertebrate(animal)

Arguably this mix of OO and procedural code is bad as well. But less arguably, the initial example (with a simple identify function) was far better than the rewrite.

oinksoft• 14 years ago

In any case the else: is pointless.

bryanh• 14 years ago

I dunno, I like the readability of an explicit else.

dustingetz• 14 years ago

its subjective, arguably a style using ternary operator is better because it is composable - it evaluates as an expression, as opposed to a series of statements. it's something the lisp and functional programming people like - no implied dependency on order in which statements execute.

i dunno if this is valid python but it demonstrates the idea

  doSomething(
    identify_vertebrate(animal) if animal.is_vertebrate() \
    else identify_invertebrate(animal))

  doSomething( if( is_vertebrate(animal)
                   identify_vertebrate(animal)
                   identify_invertebrate(animal)))

  (doSomething (if (is_vertebrate animal)
                   (identify_vertebrate animal)
                   (identify_invertebrate animal)))

this is part of "referential transparency", and once you get past "OMG parens" you realize its a Good Thing. parens are caused by a style preferring composition of expressions over executing statements, not lisp.

wging• 14 years ago

This doesn't work. I think it's an attempt at a closure, which you can do in the latest Python 3.x by `nonlocal i` as the first statement in the function definition...

  def make_counter():
    i = 0
    def count():
      """ Increments a count and returns it. """
      i += 1
      return i
    return count

pash3• 14 years ago

You can cheat in Python 2.x by giving the inner function a keyword argument that defaults to the value you want to close over:

    ...
        def count(i=i):
            ...
    ...

abecedarius3• 14 years ago

Won't do what's intended in this case. I tried it now just to make sure.

I'd use itertools.count().

perfunctory• 14 years ago

make_counter and make_adder are not equivalent. How can he compare the two?

tzury• 14 years ago

    from menagerie.models import cat as cat_models

This is not recommended at all

zackattack• 14 years ago

By whom, and why not? I like it. It's explicit. Self-documenting.

iclelland• 14 years ago

Also, it should have read

    from menagerie.cat import models as cat_models
    from menagerie.dog import models as dog_models
    from menagerie.mouse import models as mouse_models

Because otherwise it doesn't match the code in the first example for #3, and also because if your packages are ordered that way, then why not just

    from menagerie.models import cat, dog, mouse

and forget about changing the local module name.

hblanks• 14 years ago

Hi, all. I'm Hunter Blanks (hblanks@artifex.org).

Folks seem to have found a lot of implicit meaning and bugs in what was, at its grandest, a 5 minute talk at RedSnake Philly 2011. I'll just make two comments:

1) This in now up on GitHub at: https://github.com/hblanks/talks/tree/master/2011/zen_of_pyt...

so if you feel strongly about making this better, you should send me a pull request.

2) People seem to have decided that the top (or the bottom?) of every example is the more pythonic one. I suppose I should have kept a consistent order, but, as I noted in the initial HN thread, that just wasn't necessary since this was delivered in the context of a talk.

The Zen of Python (by example)

Related Stories