hblanks

(although it does leave out Otto Lilienthal)

Like many commenters here, I'm not sure I can agree with the author's position. Plenty of in-browser apps go awry, but that's most often because the tools people start using (notably jQuery) just don't work well once you have a large collection of UI components on the page.

That said, the bulk of Google's web applications, for instance, are not written in GWT or Dart, but rather in JavaScript using Closure Library, and compiled using the Closure compiler. So I don't think the answer here is to not use JavaScript (although I can understand why people at Adobe would argue for that), but rather to use tools like Closure or Angular that make the process more straightforward.

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.

This is interesting and spot-on so far as building modular, decoupled components go. Nevertheless, as the first of many Google Closure developers at Monetate, I got a lot more mileage out of Ray Ryan's great 2009 talk on Google Web Toolkit (http://www.youtube.com/watch?v=PDuhR18-EdM), of all things. He pretty much only talks about two patterns (MVP and services/event buses), but he does a great job of explaining how these apply to all sorts of parts of the application (history, RPC, display, etc.). And much to his credit, those were the only two patterns we ever needed.

Other folks might disagree, but in my experience, one of the bigger headaches to making a rich web application in JavaScript is that the class+instance model just doesn't work like you need it to -- and so in this post, we see a lot of patterns dedicated to getting around just that problem. Closure took care of that for us, so we spent pretty much no time coming up with new patterns, and instead were able to focus on writing re-usable, modular components and services from the get-go. It's not a tool I'd recommend to everyone, but if you're building a fairly high-featured web application, Closure's definitely worth looking into.

Yes, I do. Jack's an old friend an another one of the admins for Artifex.org.

By way of an afterword, I'm both pleased and surprised with the thought and attention people have given to these slides, which I made for a perhaps too hastily prepared, 10 minute talk at this Tuesday's joint PhillyPUG / philly.rb meeting. (Many thanks to the organizers, other speakers, and attendees -- it was a great turnout and a good time, too.)

I agree with several commenters that, like any collection of aphorisms, the lines in PEP 20 are not real rules but rather rules of thumb. Nevertheless, rules of thumb, or heuristics, are surprisingly important to the practice of engineering,* and perhaps even more so to the work of writing software. As such, nothing in PEP 20 should be followed hard and fast, but almost all of it is worth considering. Also as such, there's nothing (except for the comment on Guido) that makes PEP 20 relevant only to Python. It happens that these rules have a particular currency in the Python community (i.e., when people talk about being Pythonic, they're often talking about something described in the Zen of Python). But if you work in a different language, there's probably something worthwhile in it there, too.

On a different note, it is flattering to find this code, hacked out such as it was, has been reviewed by a far larger number of peers than the (comparably) few, albeit exceptional, engineers I work with at Monetate. Although it was hardly intended to be read on its own, or to run beyond the feeble purpose of generating its own slides, I have tried to correct what errors people have found. Ambiguities, of course, remain, but you can find an updated document at the original URL, or a diff of the changes at:

    http://artifex.org/~hblanks/talks/2011/pep20_by_example_2011_02_10_edits.patch

To respond to a few specific or general points:

- Yes, of course, importing from within in a function is almost always a bad idea (the only exception I've ever seen is Google App Engine, and that's obviously just a performance hack). Nor would you ever want to actually convert your floats to strings and back -- my only point there was to illustrate the fact that yes, those are the rules of floating point, and so you can't expect Python to break them for repr().

- The order of examples is not necessarily bad first, good second. (Alas for inconsistency!) So, for instance, ORMs may be complex, but they're often much better than writing your own SQL, which even in this trivial example starts to get complicated. Similarly, doctests often make code more readable than unit tests hiding in some other file -- although in honesty the doctest/unittest split is probably a false dichotomy; for some things, doctest is much cleaner, for others (like things that require setting up a DB schema first), unit tests are.

- Finally, I still didn't have the wherewithal to call pygments directly (it's certainly easy and better; I just knew the command already). But I did add HTML output, since this the web, after all, to:

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

* Cf. Billy Koen's enjoyable discussion of engineering heuristics, Discussion of the Method or Discussion of the Engineering Method. (Some chronicle is available at http://www.me.utexas.edu/~koen/OUP/HeuristicHistory.html)