Readability counts.
[...]
There should be one—and preferably only one—obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
—excerpts from The Zen of Python
This part of Python’s culture was a reaction to Perl’s motto, “There’s more than one way to do it”. Perl has been derided as a Write-only language, and despite its initial popularity, has been far eclipsed by Python. We can speculate about the various reasons, but I think this is one of them. Other ecosystems have their own cultures which emphasize different tradeoffs. Ruby, for example, seems to have inherited Perl’s take.
The Zen is full of allusions and apparent contradictions. It’s not meant to be obeyed as much as meditated upon; less about answers, and more about which questions to ask in the first place. So take my commentary as interpretation, not law.
Among other things, this part of The Zen is pointing out that code is read more often than it is written. It’s more important to make code easy to read than easy to write. It’s possible to write bad code in any language, but “bad” is partly a cultural interpretation. (And partly not.)
In Python, in the interest of readability, one should first do things in the most obvious way, until one has very good reason to do otherwise.
But “obvious” is also cultural. What is idiomatic in C is not, in Python, idiomatic (or “pythonic”), the “Dutch” part alluding to Guido van Rossum, the creator of Python, who made a lot of judgement calls about how Python was going to be, and what counts as “normal”.
So “obvious” here means “obvious to acculturated Python programmers”. It’s a warning about being “too clever”, and thereby being obtuse. But clever is OK when it’s easy to read! Are you trying to show off or are you trying to write good code? If you are an acculturated Python programmer, then you can judge what’s obvious and isn’t. But culture isn’t a static thing. If you’re a part of it, and you know better, you can push boundaries a little.
(To read all of The Zen, import this.)
My exercises for konstell are not necessarily pythonic. They illustrate particular points I was trying to teach; weaknesses I noticed in her understanding at the time. That you can do something doesn’t mean you should.
So, like anything else in Python, my main heuristic would be, does your decorator make the code easier or harder to read, for an acculturated Python programmer? Does it have benefits worth the costs? Decorators are a Python feature, and they’re used a lot. Excessive length is bad for readability too, and often neglected. Being more concise can be worth being slightly less obvious. Does it make tooling easier or harder to use? Does it make testing more or less difficult?
Re #1.
This part of Python’s culture was a reaction to Perl’s motto, “There’s more than one way to do it”. Perl has been derided as a Write-only language, and despite its initial popularity, has been far eclipsed by Python. We can speculate about the various reasons, but I think this is one of them. Other ecosystems have their own cultures which emphasize different tradeoffs. Ruby, for example, seems to have inherited Perl’s take.
The Zen is full of allusions and apparent contradictions. It’s not meant to be obeyed as much as meditated upon; less about answers, and more about which questions to ask in the first place. So take my commentary as interpretation, not law.
Among other things, this part of The Zen is pointing out that code is read more often than it is written. It’s more important to make code easy to read than easy to write. It’s possible to write bad code in any language, but “bad” is partly a cultural interpretation. (And partly not.)
In Python, in the interest of readability, one should first do things in the most obvious way, until one has very good reason to do otherwise.
But “obvious” is also cultural. What is idiomatic in C is not, in Python, idiomatic (or “pythonic”), the “Dutch” part alluding to Guido van Rossum, the creator of Python, who made a lot of judgement calls about how Python was going to be, and what counts as “normal”.
So “obvious” here means “obvious to acculturated Python programmers”. It’s a warning about being “too clever”, and thereby being obtuse. But clever is OK when it’s easy to read! Are you trying to show off or are you trying to write good code? If you are an acculturated Python programmer, then you can judge what’s obvious and isn’t. But culture isn’t a static thing. If you’re a part of it, and you know better, you can push boundaries a little.
(To read all of The Zen,
import this.)My exercises for konstell are not necessarily pythonic. They illustrate particular points I was trying to teach; weaknesses I noticed in her understanding at the time. That you can do something doesn’t mean you should.
So, like anything else in Python, my main heuristic would be, does your decorator make the code easier or harder to read, for an acculturated Python programmer? Does it have benefits worth the costs? Decorators are a Python feature, and they’re used a lot. Excessive length is bad for readability too, and often neglected. Being more concise can be worth being slightly less obvious. Does it make tooling easier or harder to use? Does it make testing more or less difficult?