A Brief Analysis of “The Zen of Python”
The Zen of Python — is a list of 19 general truths for Python design principles. Apparently there is a 20th, but I’m focusing on understanding the written list before speculating on what the Easter Egg could be. Written below is a brief analysis of each rule, taken in large part from an article I read on Quora.com. Below the list is the link for that.
Edit: Check out [X4] in the citations. They do it way better than I do!
1.Beautiful is better than ugly. — Rather than using && or|| as logical operators, consider using and || or, if it works && is readable to you. According to Soumya Ghost, “Python succeeds at being precise, concise, explicit and elegant at the same time.”[X] Is your code as pretty?
2. Explicit is better than implicit. — This may refer to “explicitly naming modules when invoking them in functions.”[X] In general, be specific. I interpret this from my days of writing poetry: be concrete, not abstract. Let your code be readable by a stranger who knows nothing about you or your program.
3. Simple is better than complex. — According to Brazilian software developer Vitor Freitas, “a simple solution is always better than a complex one.” [X3] (Try import this in Python.) Similarly, I have an idea for my first program. I want to write a lot of raw_input code for users to have only 2–3 options: Yes, No, or wrong. I want to re-route the wrong answers to again leading to a Yes or No response — or rather, x or y response — so that my users are never confused as to which responses they are prompted to give.
4. Complex is better than complicated. — I’m going to give it a go at this one. Let’s say my imaginary girlfriend asks me to make her a three-course meal for her birthday (:complex). Next, let’s instead say she asks me to take her to a restaurant she will enjoy (:complicated). Think about the main difference between Data Analytics and Data Science: in x you have the questions but not the answers, while in y you have neither the questions nor the answers.
5. Flat is better than nested. — According to the best explanation ever, flat is “… typically easier and faster to parse, and should be preferred … where you need nested data structures, prefer shallow rather than deeply nested”. [X4]
6. Sparse is better than dense. — In short, “don’t try to stick too much code on one line.”[X] Although efficiency is key (and much appreciated), being too paragraph-y will stress the reader out and make it hard to read your code.
7. Readability counts. — Many of these rules seem to overlap in their logic. Think about indentation and how much easier it is to read code that is.
8. Special cases aren’t special enough to break the rules. — Drawing once more on this lovely stranger, “languages and libraries should aim for consistency and should support the general case.” [X4]
9. Although practicality beats purity. — Regarding Rule 8, there may always be an exception to the rule.
10. Errors should never pass silently. — Never let errors, which may occur, confuse the reader. This may easily be resolved by printing a string when an error occurs.
11. Unless explicitly silenced. — Unless you are deliberately silencing the error. Even then, be clear about it. (I’m really just regurgitating the rule here. Apologies — I’m still a newbie.)
12.In the face of ambiguity, refuse the temptation to guess. — Again, this goes back to making your code specific, clear, and beautiful. I learned this the hard way from stumbling in certain Codecademy quizzes. This should be avoided even more so with your written code. Never accidentally suggest more than one option.
13. There should be one — and preferably only one — obvious way to do it. — Yet again, this eliminates confusion. According to Ghosh, this is the “exact contrary of The Perl Programming Language’s motto.”[X] In other words, think of why it would be that Python is described as an easy to learn programming language. Wouldn’t it be more difficult if you had to learn multiple ways how to do every single thing?
14. Although that way may not be obvious at first unless you’re Dutch. — This is a reference to the creator of Python, Guido van Rossum. Seeing that Guido created the Python language, it would make sense that learning or recalling a rule in Python would be easier for him than it would be anybody else, on average.
15. Now is better than never. — According to jonrsharpe, “ Don’t spend too much time planning and pre-optimising; get something down that does the job and iterate on it (or: fix that issue now rather than putting it off).” [X2]. I also imagine this as meaning ‘don’t procrastinate’ or ‘don’t put off the inevitable.’ As my granddaddy says, “Do today what others won’t do. Do tomorrow what others can’t do.”
16. Although never is often better than *right* now. — And again, quoting jonrsharpe, “ But do put some thought into it, so you don’t head off down a path that later means there’s no graceful way back.” [X2] Likewise, we usually put off what we don’t want to do. Ever have a great idea as you’re driving on the highway, or when you’re falling asleep? Similar to those situations, writing something down later is often better than at this very moment, but again, if we don’t do it now, the chances of it being done decreases.
17. If the implementation is hard to explain, it’s a bad idea. — If the implementation is complicated, it is definitely not simple, meaning it is nowhere near a final draft, meaning it’s not good to put out as one.
18. If the implementation is easy to explain, it may be a good idea. — According to — now I know his name! — Steven: “some ideas are just bad, regardless of whether they are easy to implement or not.”[X4]
19. Namespaces are one honking great idea — let’s do more of those! — Google defines a namespace as “a set of symbols that are used to organize objects of various kinds, so that these objects may be referred to by name.” This still confuses me, so let’s see what we have here: Symbol sets, and various objects referred to by name. I suppose in general language, a word is defined by other words. Once learned, we need only the one word — or, namespace? — to make sense of something, making life simpler in the process.
Have simpler ideas on what The Zen of Python mean? Feel free to contact me through here! Or at Pythonidaer@gmail.com. See below for citations.
[X] → https://www.quora.com/What-do-different-aphorisms-in-The-Zen-of-Python-mean
[X3] → https://simpleisbetterthancomplex.com/about/
[X4] → https://mail.python.org/pipermail/python-list/2010-October/590762.html
