Where is Zen of Python?

en in code • 3 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 the possibility of ending function call from other functions. I realized 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 its 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 has 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! `“

Excellent list of pearls of wisdom!

“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. A few years back, it was apparent we should use only format method. Today? We already have Python 3.8, but is it OK to use f-string already? Fellow developers can love it, but what about compatibility?

If you argue with a shorter syntax and performance support, I can understand. But, is the shorter syntax always better? Maybe I’m just scared of 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 in Python.

You may also like

en Makefile with Python, November 6, 2017
en Fast JSON Schema for Python, October 1, 2018
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

More posts from category code.
Do not miss new posts thanks to Atom/RSS feed.

Recent posts

cs Mami, tati, přejde to, December 9, 2023 in family
cs Co vše bychom měli dělat s dětmi?, November 24, 2023 in family
cs O trávicí trubici, November 7, 2023 in family
cs Na šestinedělí se nevyspíš, October 28, 2023 in family
cs Copak to bude?, October 20, 2023 in family