Zen of Python, Again
There used to be a different blog here which I started in March 2012. The first entry was called “The Zen of Python and Me” where I went through each of the koans and explained what it meant to my day-to-day Python programming. What changed since then?
What’s “Zen of Python” anyway?
It’s a set of aphorisms by Tim Peters that summarize some fundamental idiomatic recommendations within the spirit of the Python programming language. It’s a typical example of Tim’s wit and insight.
The Zen was originally posted on the comp.lang.python newsgroup in June 1999, to be later extracted as PEP 20 and even a CPython interpreter Easter egg: import this.
A Sense of Cohesion
Although the Zen was always somewhat of a joke, and it was created almost a decade after the first public version of Python saw the light of day, I was fascinated by it when I discovered it and took it very seriously.
It felt both like a design statement and a Martin Luther-style “95 theses” challenging the authority. At the time that authority was very obviously Java, in fact the original thread the Zen appeared in was a discussion about rewriting Python in Java.
At the time to me the theses in Zen of Python read like a manifesto: a declaration of rebellion against boilerplate, rigid structures, corporate overlords, lengthy compilation steps, you name it. I bought into that.
I’m sure I wasn’t alone in this, the existence of the Zen of Python and discussions on what’s Pythonic were both very attractive to newcomers. Here was a community that apparently had a cohesive idea about what computing should look like and how it should feel like. I think for that alone the Zen of Python should be considered an important artifact in Python’s history. It was a contributing factor to Python’s rise in prominence.
No Time Machine
Of course, the notion of having a comprehensive, consciously laid out plan that Guido and his early contributors followed when creating Python was at best aspirational. Python users liked to say that Guido had a time machine since every now and again it seemed like he created a feature in the past for a need that has just arisen much later.
In truth, it’s hard to overrate Guido’s initial taste and insight about what makes Python tick. But to say that he had a plan from Day 1 is a stretch. A good example of this is his blog post on the inclusion of user-defined classes where he admits that he added multiple inheritance without thinking much about the consequences of that design, and even calls himself “fairly naïve about classes” at the time.
In the original Zen of Python post, Tim adds:
I make shit up as I go along – & Guido often appears to think that my fabrications would be good positions for him to have pretended he had all along too.
Clearly the Zen of Python was never actually part of the design process for Python, not in the first decade but also not in the decades since.
Beating Heads with Bibles
While the nuance of the Zen of Python being more of an art form rather than a design document wasn’t lost of me, I still liked to think of it as a pragmatically useful set of guidelines.
This is how I approached the Zen of Python in my original 2012 blog post about it. Today it reads like a sermon by some small town priest.
Apparently many other inexperienced people liked to treat the Zen of Python with similar gravity, to the dismay of senior Pythonistas. In fact, last time I used the Zen of Python in a design discussion with Guido, he was pretty blunt about his frustration:
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. :-)
Form Without Form
Now we’re hearing voices that maybe the Zen of Python should be removed from the interpreter, or that it should be clearly described as a joke in PEP 20. Is it useless?
The Zen of Python is deliberately self-contradictory, as it articulates competing design principles to take into consideration, rather than being able to provide ironclad rules that avoid the need for human judgement in determining which of those design guidelines are most salient in any given situation.
– Nick Coghlan
I tend to agree with this position. The Zen of Python has value in that it makes you think about the design dimensions it touches on. While its prescriptions are so broad you can explain anything with it using enough mental gymnastics, ultimately it is about some sense of elegance, some sense of Quality.
Looking at my original blog post, I see I quoted Robert M. Pirsig, Antoine de Saint Exupéry, H. L. Mencken, “Structure and Interpretation of Computer Programs”, in other words: artists. That part I agree with today as well. A lot of what we’re doing as programmers is about aesthetics, about choosing solutions that “feel right”.
In this sense, while it’s important to acknowledge that the Zen of Python is not a cookbook, I am still a big fan of it, as it continues to communicate that what we’re doing is more than plumbing, and asks us to consider Quality, even if that’s subjective and emotional.