Additional BDFL Wisdom for PEP20?

I was restudying PEP8 as I generally do every 12 months or so and came across some wisdom that reminded me of PEP20:

A Foolish Consistency is the Hobgoblin of Little Minds
“One of Guido’s key insights is that code is read much more often than it is written.”

That nugget of wisdom might bear inclusion into the Zen of Python as something like…
"Wise Hobgoblins know that style and readability matter because code is read much more often than it is written."

Your thoughts?


1 Like

How will I ever fit that into the Zen of Python song? :grin:


Isn’t that just a longer way of writing “Readability Counts.”?

And don’t you find that the Zen of Python often gets misunderstood?

Like misquoting “There should be one obvious way to do it.” and missing that the em dashes are styled differently? As well as people getting attached to their specific interpretations of certain lines?

I feel that adding more lines to it is likely to cause lots of contentious discourse and bike-shedding.

1 Like

That’s a worthwhile question, Damian, and readability is definitely one of the two topics expressed in the PEP8 reference. I edited my original post to add the ‘readability’ part, having initially only referred to style as the practical point. I had left readability out because, as you pointed out, it’s already covered in the existing principia.

What I’m proposing here is that PEP20 elevate the theory behind/beneath style and readability: code is read more often than it’s written. The reference to hobgoblins somehow encouraged me to add the extra verbage about style and readability. (Sometimes even wise hobgoblins benefit from additional explanation. :smiley:)

Nevertheless, if the phrase were lightened up to strip out the redundancy, then it could possibly earn its place among the plain and sensible principles delineated in PEP8. That offers us…
Wise hobgoblins know that code is read much more often than it is written.

Stripping it down to its bare essentials gives…
Code is read far more often than it is written.
…though I do think that the reference to hobgoblins is both appropriate (since it echoes the original source in PEP8) and a lot more fun. @barry can choose which version to use on the Zen of Python Song Redux. After all, some rationale to release a “producer’s cut” version of the PyLadies album is a good basis for another round of fundraising.

Yes. Philosophy inherently includes that possibility. Jokes do, too-- at least the nonobvious ones.

Bike sheds are a fine place to store a hobbyhorse. :cowboy_hat_face: My impression of the community here is that conscientious discussion is more likely than contentious, especially regarding a fundamental principle.

IMO this reading is common but mistaken.

The hobgoblin line can be understood to mean that inconsistent style is a problem. When you contribute to Python (or some other mature projects), you learn to balance style with unwanted churn, possible risks with seemingly-innocent changes, perturbation of VCS history, using contributors’ time for actual fixes and improvements, etc.

The way I understand that line now (after some time + searching for the context of the original quote) is quite opposed: don’t let yourself be bedeviled by insignificant style nits!

“A foolish consistency is the hobgoblin of little minds” is a quote
from Ralph Waldo Emerson’s treatise on “Self-Reliance” wherein he
argues that people who object purely to someone’s words and phrasing
are, in essence, missing the meaning behind those words and so
merely grasping at something superficial instead.

When applied to coding style, it’s a way of implying that style is a
secondary to functionality, and that “rule lawyers” who are focused
exclusively on enforcing style even over reasonable objections are
small-minded and should revisit their approach. Specifically in the
context of PEP 8, it’s clearly called out as a “gut check” for
deciding when and how to apply style rules:

“know when to be inconsistent – sometimes style guide
recommendations just aren’t applicable. When in doubt, use your best

The Zen of Python is not a living document to be maintained and adapted.

It is a joke from the earliest days of the Python that far too many people take too seriously.

It is the first entry in the Python humour page. Tim Peters explicitly explains one of the jokes here on the bug tracker. And in the best tradition of Zen koans, none of them have a straightforward, easily understood meaning.

What exactly is the difference between complex and complicated? Is flat really better than nested? Imagine if our file systems were still flat, without directories. Its well and good to say that beautiful is better than ugly, but how do you know if your code is beautiful or ugly?

And if you still don’t get the joke, then read the source code to the module and see how many of the Zen koans it violates…

It is true that, cleverly disguised as humour, the Zen of Python contains a few nuggets of good design principles. Or at least food for thought. But one can write entire books on design principles. 20 koans doesn’t even scratch the service.


Read about my recollection on how PEP 20 and import this came about.

1 Like

That’s a nice read; thanks! :slight_smile:

These are valid questions, Steven. The thread topic is supposed to be “code is read much more than it is written” (I tried to edit the title and original post to clarify this but the edit period has lapsed) but I think your questions, rhetorical though they may have been intended, more than deserve to be honored with an answer.

What exactly is the difference between complex and complicated?

Complex: made up of many simple elements, as in a readily-evident compound structure or system.

Complicated: a relationship of parts that interact and affect each other in elaborate, often obscure ways.

Though these two terms, complex and complicated, are easily intermingled, the difference is the clarity versus obscurity of the relationships between the elements of a multi-part system.

Is flat really better than nested?

Since the context is programming, one might consider the difference between a routine with many nested levels (indents) versus using a function call. Code folding also creates “flatness”; I put a fair amount of thought into structuring commented lines to create convenient “creases” in VS Code and other auto-folding IDE’s. This routinely involves blatant violation of the 4-space indent, but it’s a very limited exception, improves readability and assimilation tremendously, and is a net gain. Another example of flatness in practice would be a short IF: clause that integrates better as a single line rather than LF+indent. This effect is exponential when you can use multiple consecutive one-line IF: clauses.

how do you know if your code is beautiful or ugly?

Excellent question, and this illustrates the philosophical and sometimes subjective nature of the pyZen principles. Nevertheless, we can delineate some fundamental concepts and pierce the darkness. To wit:

Some levels in the aesthetic scale might be…

  • Beautiful
  • Elegant
  • Workable
  • Crude (but effective)
  • Sloppy
  • Ugly
  • Painful, Torturous, Evil, etc.

“Beautiful” and “ugly” are subjective by definition, so a subsequent programmer’s experience defines where on the scale any given code might be–for them–which means that the skill, experience, and depth of knowledge of that follow-on programmer is a major factor in the achievement of beauty. An example: Someone unfamiliar with matrix math won’t perceive the beauty of solving simultaneous quadratic equations with code. I initially studied matrices in high school and again while getting an engineering degree but they didn’t make sense and even seemed a bit pointless. In graduate school I finally had someone explain it properly (or perhaps I had cleared up some underlying confusion) and was stunned by the simplicity and beauty of matrices.

The final analysis: You know where on the scale you and your code are by how pleasurable it is to create the code or work with it afterward.

It seems that the Beauty statement is largely aspirational, particularly when a deadline looms, but most programmers who code as a hobby have experienced elegance and beauty in coding. Sometimes the experience is best described as ecstasy. Taking a slightly different tack on it: Simplicity is genius (git is an example) and benevolent demonstrations of genius are extremely pleasurable and therefore almost always beautiful.

Speaking of git, that’s also an excellent example of complexity versus complication.

Closing thought: Evidently the pyZen principia would act as koen by encouraging the reader to more deeply consider the meanings of the words it contains. I find most of them to express fundamentals that I’ve arrived at over the many decades. (The decades since my dad brought home a hot-rod Tandy TRS-80 with an external 128K memory expansion unit. The memory expansion “appliance” was a good bit larger than a modern laptop.) For some time now, all of my protégés receive an orientation on complex versus complicated and the “junk food” of shortcuts and clever solutions–that usually create problems later–versus the genius and beauty of complete and well-considered solutions.

don’t let yourself be bedeviled by insignificant style nits!

Absolutely! A slave-ish/slavish devotion to policy, convention, or standards is a form of deep irresponsibility. One has to be able to think with the policy, standard, convention, or principle to apply it well and sanely. Being a robot doesn’t relieve one from the responsibility of deciding to act or not act, and how to act.