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

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 http://www.me.utexas.edu/~koen/OUP/HeuristicHistory.html)