Where is Zen of Python?

en in code • 5 min read

I tried Ruby once. I found Ruby interesting language because of a lot of features making the code less verbose. One of the awesome features, at least I thought at that time, was possibility to end function call from other function. I realised very soon that with many options, it’s actually hard to follow the execution flow. And what’s worse, it’s harder to combine libraries together. I hated that each library in Ruby had own opinion about how to provide a good interface.

I stayed loyal to Python, which I find awesome. It’s not perfect and I can feel your arguments. I have even my own arguments! But I love Python. Python can be used almost anywhere and you can find a library for almost anything you can imagine. And Python have a Zen of Python.

If you don’t know about it, run import this in your favorite Python shell, you will get the following result:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
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.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Very good list of wisdoms!

“There should be one-- and preferably only one --obvious way to do it.” is the one I appreciated the most and liked Python even more after I tried Ruby.

Now I’m curious, where is it?

First, we had formatting using % (modulo) operator. It was ok-ish, but not robust enough. So we got format method on string object which solved all possible shortcomings. And since Python 3.6 we have f-string.

Why? If I will count a very old template strings, and simple concatting, it makes five options how to format a string! Where is the preferably one obvious way?

There is not one way anymore, definitely not obvious. Few years back it was obvious we should use only format method. Today? We have already Python 3.8, but is it OK to use f-string already? Fellow developers can love it, but what about compatibility?

If you argument with a shorter syntax and performance support, I can understand. But, is the shorter syntax always better? Maybe I’m just scared from expressions hidden in the string… either way I think it’s better to be explicit. And readability counts! :-D Also, I think it would be possible to make performance speed up even for format method. I can imagine how complicated it can be, yet not impossible.

As I said, we have Python 3.8 now with few more features. Another syntax for assigment or another syntax for positional-only parameters. So many choices now, so many choices…

I’m afraid what else will be included into Python.



Share on:   Facebook   Twitter   Reddit   Tumblr   Pinterest




You may also like

en What Makes Good Program?, November 20, 2018
en Old Code, October 31, 2018
en Fast JSON Schema for Python, October 1, 2018
en Open Source Responsibilities, September 6, 2018
en Deployment of Python Apps, August 15, 2018


Popular from code

en Makefile with Python, November 6, 2017
en Deployment of Python Apps, August 15, 2018
cs Jasně, umím Git…, August 6, 2014
cs Checklist na zabezpečení webových aplikací, March 1, 2016
cs Pokročilé regulární výrazy, August 17, 2014