What is Pythonic?

In a pull request comment, I saw someone tout NumPy’s format approach as Pythonic:
with np.printoptions(precision=3):
I want to argue it’s not Pythonic. But I’m not sure I have a rule to explain why. What do you think? Does it look Pythonic? Why or why not?

Brandon Rhodes recently commented on Twitter that he had seen a feature of NumPy that someone had said was Pythonic. He wanted to argue the contrary, but unsure he had an authoritative reason as to why. So he opened it as a question.

I responded with: "Pythonic? I thought that ship sank years ago... I've lost the meaning of Pythonic. Is it an idiom, a style, a custom, a law, a standard to divide the enlightened from the heretics?"

Two questions come to me immediately, First, "What does Pythonic mean in 2021?" Second, "What's going on in that piece of code?"

Early in my career's Python era, I was pretty sure that Pythonic meant code that leveraged the idioms and innovations of the language in a manner different from other languages.

I read PEP-20's "Zen of Python" a couple years later. There were many statements that I agreed with and several that I did not. I didn't think of the Zen of Python as the definition of Pythonic, it's way too vague. I appreciated the thing as an aphoristic Easter Egg in the interpreter, not scripture.

As the years progressed, the calls for style standardization became louder and louder. The definition of Pythonic shifted to be that which simultaneously cleaves to both the rigidity of PEP-8 and the ambiguity of PEP-20.
Pythonic is Good, not Pythonic is Bad.

By that definition, I'm not convinced that great swaths of the language itself are Pythonic. Some things are obviously ugly; there is more than one obvious way to do many things; there are features that are hard to explain. What is obvious to me is not necessarily what is obvious to an Atmospheric Chemist in India or a Quantitative Analyst on Wall Street. This is a good thing. If it were otherwise, we would all think alike: the bane of innovation. Monoculture is weak. The label Pythonic is too nebulous to be useful for anything other than drawing exclusion zones around people expressing ideas in a manner that represents their thinking style, education or professional culture.

That finally gets me to the code:

with np.printoptions(precision=3):

It looks like a context manager setting something behind the scenes that changes the way that objects defined in the NumPy module are converted to strings. This was instantly obvious to me solely based in my experience of both the with statement and NumPy. All uses of a with statement without a corresponding as clause are hiding something behind the scenes, it's part of the language.

The earliest years of my career were all about Fortran. Python'sNumPy module feels very Fortran. NumPy is Fortranic because it embraces the idioms common in Fortran Numerical Analysis, the lingua franca of scientific computing. The importation of the style/idiom into Python ensures that NumPy is both attractive and familiar for those in Scientific Computing migrating to Python.

You can support my
programming and writing
on Patreon or Ko-fi
Retirement is tough.
Even small
contributions help.

Python is an incredibly flexible and accommodating language. Code written in Python can be functional, procedural, object oriented, declarative or most importantly, any combination of these. The flexibility of expression is part of the language. This is one of Python's greatest super powers

The Pythonic with statement is a clear candidate for Python's Top 10 Feature List. This use of a context manager (of which there are several obvious ways to implement) ensures the orderly behavior of a Numerical Analysis system with roots in Fortran. This is an ideal example of the melding of ideas enabled by Python. The NumPy module has state. It may not be a modern idea, but it is the way NumPy is written. By using with statement and context, the code clearly telegraphs the message that the state is changed and will be mindfully restored at the end of the context. That's to be celebrated: a Pythonic glue. Diversity of style, methodology, and idiom is a strength, not a weakness to avoid.

These days in retirement, I program only for myself. I can express myself freely in code without worrying about upsetting the sensibilities of those interested in neither diversity of thought nor compromise (more on my use of the 'Black' style formatter some other time).

Some would say there is only one correct way to write software in Python.


PEP-20 is a poem, not a seed document for a judicial system.