Confusion regarding a rule in The Zen of Python

The Zen of Python has a rule,

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

but this rule appears to be getting broken everywhere.
for example,

  1. different ways to update a dictionary, dict.update(), |, {**x, **y}
  2. use of namedtuple vs enum
  3. different ways to split a string
  4. using list, set, dict comprehensions vs map, lambda functional way to achieve the same
  5. use of property decorator vs achieve the same using descriptor
  6. the whole point of timing different ways to achieve a particular task is a violation of this rule

plus it even creates doubt when suggesting a change.

1 Like

I think that PEP 584 – Add Union Operators To dict addresses it (i.e. dictionary part and in general) pretty neatly:

Only One Way To Do It

Dict union will violate the Only One Way koan from the Zen.


There is no such koan. “Only One Way” is a calumny about Python originating long ago from the Perl community.

More Than One Way To Do It

Okay, the Zen doesn’t say that there should be Only One Way To Do It. But it does have a prohibition against allowing “more than one way to do it”.


There is no such prohibition. The “Zen of Python” merely expresses a preference for “only one obvious way”:

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

The emphasis here is that there should be an obvious way to do “it”. In the case of dict update operations, there are at least two different operations that we might wish to do:

  • Update a dict in place : The Obvious Way is to use the update() method. If this proposal is accepted, the |= augmented assignment operator will also work, but that is a side-effect of how augmented assignments are defined. Which you choose is a matter of taste.
  • Merge two existing dicts into a third, new dict : This PEP proposes that the Obvious Way is to use the | merge operator.

In practice, this preference for “only one way” is frequently violated in Python. For example, every for loop could be re-written as a while loop; every if block could be written as an if / else block. List, set and dict comprehensions could all be replaced by generator expressions. Lists offer no fewer than five ways to implement concatenation:

  • Concatenation operator: a + b
  • In-place concatenation operator: a += b
  • Slice assignment: a[len(a):] = b
  • Sequence unpacking: [*a, *b]
  • Extend method: a.extend(b)

We should not be too strict about rejecting useful functionality because it violates “only one way”.


Is it not the case that The Zen of Python should be considered as more of a guide than list of rules? [1]

  1. rhetorical ↩︎


Zen of Python was never meant to be a rule. Take a look at this post by Lukasz Langa for further details.

Summarizing it in Guido’s words:

“It’s poetry, not a set of axioms. You can’t prove anything with an appeal to PEP 20. You can appeal to it, for sure, but such an appeal by definition is subjective and emotional. (There’s Only One Way To Do It? Give me a break. :-)”


The Zen of Python is a joke that has been elevated up to the position of Holy Writ in the minds of some people, but it should not be taken too seriously. Especially not the One Obvious Way koan, which has been explicitly described as a joke by its creator, Tim Peters.

The Zen is the very first entry in the “Python humour” page so beware of people who take it too seriously.

We can use the Zen as a list of useful design principles, so long as we remember that:

  • not all useful design principles are included;
  • such as “syntax should not look like grit on Tim’s monitor”;
  • they are guidelines, not laws;
  • we should treat them as the start of the discussion, not the end.
1 Like

Is it not the case that The Zen of Python should be considered as more of a guide than list of rules?

Not only is this the case, but it’s expressed in the introduction to PEP20:

Tim Peters succinctly channels the BDFL’s guiding principles for Python’s design into 20 aphorisms.

PEP20 is a list of principles and aphorisms with several jokes thrown in. Neither frivolous humor nor canon, dogma, or catechism it be.

Most everyone probably knows what a principle is: a first/foremost concept. Literally “Thing to grasp first”.


  1. A tersely phrased [compact] statement of a truth or opinion.
    (Synonym: “a saying”)
  2. A brief statement of a [scientific] principle.

So they definitely aren’t rules. They aren’t even “policy”. Policy is a pseudo-rule that, except for certain catastrophic situations, provides guidance rather than an edict. Good policy should be based on actual experience rather than attempting to enforce some arbitrary version of an ideal organization. The nature, development, and application of good policy is a whole additional subject.

They’re somewhere between philosophy and theory. You find them applied in practice through style guides and coding guidelines and conventions (all of which are forms of policy). A good style guide will have the best practices layered in categories of “recommended”, “desired”, and “mandatory”. The pyZen principles are in the ‘recommended’ group and should be self-evident enough to naturally flow into a ‘desired’ status.

The principles are simply expressions of some building blocks of a certain mindset that leads to best practices. Rather than being edicts, they’re gentle urgings toward a mindfulness that leads to right action. NOTE: this is different from a “koan”, which is a phrase that’s designed to deconstruct your assumptions. They aren’t koan any more than they’re mantra for meditation.

We might want to consider ichigi (Japanese “ee-chee-gee”) or yimu (Chinese “ee-moo”),which both mean first ~principle/~meaning/~reason/~consideration. Koan does have the interesting correlation with “kohen” (priest), though that tends toward complicated rather than complex or simple–which might be a compelling reason to evolve from ‘koan’ in addition to the fact that its definition doesn’t truly apply.

The originally-posted pyZen principle has some key terms:

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first…

These are qualifiers that preclude the principle from being anything close to mandatory.

And one can probably safely add “…way to do it in a given context.”