Python rules

From AJS.COM

This article has been updated and re-posted as a blog entry on Aaron's Essays

Python has many rules of conduct, which are summed up in a short list of aphorisms by Tim Peters.[1] I'd just like to comment on those because, while I like Python, the dogma surrounding the language is particularly unfriendly to the kind of programming that, surprisingly, tends to work well in Python and thrives in its many add-on modules.

Beautiful is better than ugly.

That's easy to say, of course, but what's ugly? Before I programmed in Python, I considered blocking with whitespace ugly, but now that I'm used to it, it's a non-issue. If I didn't program in C, perhaps I'd consider putting * before pointers ugly... but again, it's a matter of experience and acclimation, just like Python. What's really ugly, and always will be, is code that makes experienced programmers in a language wince, so this should really be:

Beautiful python in the eyes of an experienced python programmer is beautiful.

Not as catchy, I'll admit.

Explicit is better than implicit.

This, I just can't agree with. There's an awful lot of implicit behavior in the core Python language, from type management to typical OO implicit behaviors. There's nothing wrong with any of this. What's a problem is when implicit becomes the norm to the point that there is a constantly evolving learning curve, rendering even previously expert knowledge moot.

Simple is better than complex.
Complex is better than complicated.

There's a bit of implied definition going on here that I'm not sure a reader can grasp without knowing the author. The difference between complex and complicated isn't actually well understood from reading their definitions.

Flat is better than nested.

My personal preference is to disagree with this at nearly every turn, but this debate goes back as far as the early normalization arguments surrounding relational databases. I don't see it being resolved soon, and certainly Python's better libraries are so full of excellent counter-examples that the point isn't really worth arguing in this context.

Sparse is better than dense.

Again, I'm not sure that there are few enough parameters in that mix to reasonably evaluate the statement. Sparse what? Dense what? Code? I've seen some dense code that worked and read quite well. I'd say the next rule actually covers this ground much better.

Readability counts.

Corret, of course, though note the response to the first item, above.

Special cases aren't special enough to break the rules.

This is wishful thinking, and if it were true, then programming languages would be trivial things to write. For example, if this were true, you would never write a regular expression in a special syntax. You would just call a library that provided all of the tools of an RE. It turns out, however, that matching text is a special case that's special enough to break the rules. It would just be too much work to write (or read) such code. REs are terse enough to be quickly scanned and understood, where sprawling code that implemented the same via a state engine would be nearly impenetrable.

Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.

I'm not sure how to parse this, or how it follows grammatically from the above. That said, the concept is reasonable, even if easily taken to a useless extreme (your kernel should never exit with a stack trace because an ethernet packet was corrupt). In fact, security isn't touched on here, but many error-handling approaches imply significant opportunities for denial of service, and this must be carefully avoided.

In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.

This is a guiding principle of Python, but it's fundamentally flawed. I think Twisted has shown us this best by providing radically different, and yet equally valid ways of interacting with traditional programming tasks such as network communication. At the very lowest level, it's often possible to identify a specific, short section of code which should only be done one way. Adding two numbers, for the most part, should be done with +. Other ways could be used, but they're clearly far more cumbersome and only have advantages in some very specific cases. There's a touch of hubris implicit in claiming that there's a right way to do anything.

Although that way may not be obvious at first unless you're Dutch.

What was I saying about hubris?

Now is better than never.
Although never is often better than *right* now.

Sure, I guess. There are lots of ways to take this... Certainly as an expression of Knuth's observations about premature optimization this is quite reasonable.

If the implementation is hard to explain, it's a bad idea.

This is another over-generalization that is often incorrect. The implementation of regular expressions or grammars are exceedingly difficult to explain, except to those who have worked with them long enough to understand them well. They are, however, an excellent idea.

If the implementation is easy to explain, it may be a good idea.

This is certainly fair if somewhat moot.

Namespaces are one honking great idea -- let's do more of those!

I think every language created over the past 20 years has stumbled on this truth, and it's one that certainly resonates through lots of great code.

My version

So, here's my version of the text:

Always be aware of the trade-offs involved in your code and always make those choices with the perspective of prospective maintainers.