Breaking the Zen of Python

I'm not going to slaughter a sacred cow here. But I'm going to poke it enough to irritate it...

One of the exemplary, epic engineers reading this blog wrote me an email...

Taking exception to part of the "Zen of Python" (you can search for it).

Specifically:

"There should be one - and preferably only one - obvious way to do it."

What he pointed out:

Is this principle of "only one way" reasonable in a complex world of real software, developed by teams?

I LOVE this question. My take:

First, you can think of this "one obvious way" principle as more a guiding idea for Python. Rather than an unbendable rule.

And the asterisk on this principle is: "when it makes sense to have just one way to do things."

It's important to point out: there are LEVELS of software this applies to more than others.

The principle mainly applies at the language statement/idiom level. Less so at the design-pattern level, and even less at the architectural levels - where there are many valid ways to decompose your business logic and data representations.

But more importantly:

This principle - and the whole Zen of Python - is simply a CHOICE that was made, about what kind of language Python would be. A choice that has guided its design and evolution over time.

Contrast with Perl's TMTOWTDI principle, a.k.a. "tim toady". Short for "There's More Than One Way To Do It". The philosophy of THAT language has been to give users many options at the statement/idiom level.

The opposite of Python's, in a sense. Nothing wrong with that; it's not better or worse, just a different choice.

There's plenty of examples where Python has ended up not having "just one way to do it". String formatting is probably the most blatant example.

(Turns out steadily evolving one of the most popular programming languages in human history, over several decades, is harder than it looks!)

Practically, the point boils down to: Don't worry about it too much.

It's useful to understand the ideas behind a programming language. So you know how to code in harmony with it, rather than fighting against it.

But don't be afraid to deviate from it, or be concerned when that language seems to deviate from its own philosophy. Real coding languages, like real people, aren't perfect.

And just like with people, we love 'em anyway.