{"id":21,"date":"2022-04-02T00:16:31","date_gmt":"2022-04-02T00:16:31","guid":{"rendered":"https:\/\/codecrypt76.com\/?p=21"},"modified":"2022-11-25T16:48:47","modified_gmt":"2022-11-25T16:48:47","slug":"the-zen-of-python","status":"publish","type":"post","link":"https:\/\/codecrypt76.com\/index.php\/2022\/04\/02\/the-zen-of-python\/","title":{"rendered":"The Zen of Python"},"content":{"rendered":"\n
\"Zen<\/figure>\n\n\n\n

The Zen of Python<\/em> by Tim Peters, also know as PEP 20<\/a>, is a collection of guiding principles designed into 20 aphorisms, only 19 of which were written. Guido van Rossum reportedly said that the missing 20th aphorism is \u201csome bizarre Tim Peters in-joke\u201d (Sweigart, 2018). Your Python code doesn\u2019t have to follow this guidelines, but they\u2019re good principles to keep in mind. The Zen of Python is an Easter Egg<\/em> that appears if you run import this<\/code>.<\/p>\n\n\n\n

>>> import this\nThe Zen of Python, by Tim Peters\n\nBeautiful is better than ugly.\nExplicit is better than implicit.\nSimple is better than complex.\nComplex is better than complicated.\nFlat is better than nested.\nSparse is better than dense.\nReadability counts.\nSpecial cases aren't special enough to break the rules.\nAlthough practicality beats purity.\nErrors should never pass silently.\nUnless explicitly silenced.\nIn the face of ambiguity, refuse the temptation to guess.\nThere should be one-- and preferably only one --obvious way to do it.\nAlthough that way may not be obvious at first unless you're Dutch.\nNow is better than never.\nAlthough never is often better than *right* now.\nIf the implementation is hard to explain, it's a bad idea.\nIf the implementation is easy to explain, it may be a good idea.\nNamespaces are one honking great idea -- let's do more of those!<\/code><\/pre>\n\n\n\n
Analysis<\/h2>\n\n\n\n
1. Beautiful is better than ugly.<\/h3>\n\n\n\n
Words like \u201cBeautiful\u201d and \u201cUgly\u201d are subjective terms. However, in Python, your code should strive to be readable, constant and visually elegant.<\/p>\n\n\n\n
2. Explicit is better than implicit.<\/h3>\n\n\n\n
Explicit denotes being very clear and complete without vagueness, implication, or ambiguity. When something is said to be explicit, there is no question as to what is being expressed or conveyed\u2014nothing is implied or assumed.<\/em> Implicit<\/em>, on the other hand, denotes that something is understood although not clearly or directly expressed or conveyed\u2014there is implication, assumption, or question. Obviously, when writing Python code, your code should strive be explicitly clear.<\/p>\n\n\n\n
3. Simple is better than complex<\/h3>\n\n\n\n
\u201cSimple can be harder than complex: you have to work hard to get your thinking clean to make it simple. But it\u2019s worth it in the end because once you get there, you can move mountains\u201d<\/em><\/p>\u2013 Steve Jobs<\/cite><\/blockquote>\n\n\n\n
In Python, your code should excel for its beauty and readability, without losing its simplicity! In other words, when developing Python code, don\u2019t look for the most complex path! Try to keep it simple! Finding a simple solution to a simple problem should always be your goal, even if it is not that simple to do!<\/p>\n\n\n\n
4. Complex is better than complicated<\/h3>\n\n\n\n
When the simple alternative is not possible, avoid the complicated solution! However, sometimes a complex problem requires a complex solution.\u2026But always remember, a complex solution is better than a more complex one!<\/p>\n\n\n\n
5. Flat is better than nested.<\/h3>\n\n\n\n
Avoid creating structures inside structures that are inside another structure. Sweigart (2018) jokingly points out a common trait among programmers is the predilection to organize things into categories, especially categories that contain subcategories which contain other sub-subcategories. This statement is very True. However, excessively nesting constructs like conditional statements, functions, classes or modules one inside the other is frowned upon and should be avoided.<\/p>\n\n\n\n
6. Sparse is better than dense<\/h3>\n\n\n\n

In other words: don\u2019t try to \u201ccram\u201d too much code into one line. Programmers have a tendency to try and cram as much functionality into as little code as possible as evident with the following one-liner code:<\/p>\n\n\n\n
print('\\n'.join(\"%i bytes = %i bits which has %i possible values.\" % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))<\/code><\/p>\n\n\n\n
Although this impressive code resembles solutions you might see on CodeWars<\/a> or HackerRank<\/a>, this code will irritate your coworkers who will have to try to decipher it. Remember the first topic: \u201cbeautiful is better than ugly\u201d!<\/p>\n\n\n\n
7. Readability counts<\/h3>\n\n\n\n
The motto of Python is clarity. The language attempts to be as readable as the English language.<\/p>\n\n\n\n
I\u2019d like to mention one readability rule specifically: punctuation characters should be used conservatively, in line with their common use in written English or high-school algebra.<\/p>\u2013 Guido van Rossum<\/cite><\/blockquote>\n\n\n\n
It is recommend not to drop vowels from variable names or write overly terse code. Code is read more often than it\u2019s written, so explicit, readable code is more important than terse, undocumented code (Sweigart, 2018).<\/p>\n\n\n\n
8. Special cases aren\u2019t special enough to break the rules.<\/h3>\n\n\n\n
In General, programmers should always strive to adhere to best practices when coding. Sometimes it\u2019s tempting to cut corners for a quick hack but this can lead to a rat\u2019s nest of inconsistent, unreadable code.<\/p>\n\n\n\n
9. Although practicality beats purity<\/h3>\n\n\n\n
However, Sweigart (2018), points out, \u201cbending over backwards to adhere to rules can result in highly-abstract, unreadable code.\u201d It is important to remember, no case is special enough that it bypasses the rules! Even if practicality supersedes purity!<\/p>\n\n\n\n
10. Errors should never pass silently.<\/h3>\n\n\n\n
It is better for a program to crash than to let Errors pass silently. The bugs that will inevitably generate will be more difficult to catch in the future if errors are suppressed. Never \u201csilence\u201d an exception unless it is explicitly stated and silenced. Muting an exception is a serious code maintenance error as it can hide an error, sometimes harmless, sometimes critical! So pay attention! Do not do it<\/p>\n\n\n\n
11. Unless explicitly silenced.<\/h3>\n\n\n\n
Although you can choose to explicitly ignore the errors caused by your program, just remember there are consequences for doing so.<\/p>\n\n\n\n
12. In the face of ambiguity, refuse the temptation to guess.<\/h3>\n\n\n\n
Again, this has to do with making your code specific, clean, beautiful and related to the next Zen.<\/p>\n\n\n\n
When your code does not work, never be tempted to blindly try various solutions until something seems to work. Often this leads to merely masking the problem rather than solving it (Sweigart, 2018). More often than not, critical thinking and analysis of the problem will lend itself to a solution.<\/p>\n\n\n\n
13. There should be one\u2014and preferably only one\u2014obvious way to do it.<\/h2>\n\n\n\n
According to Sweigart (2018), This is a crack against the Perl programming language\u2019s motto, \u201cThere\u2019s more than one way to do it!\u201d in Python it is preached that there should be only one way to reach a solution to the problem. That\u2019s one of the reasons Python makes it so simple. Unfortunately, this aphorism did not prevent Python from incorporating three different ways of formatting strings. Sometimes, having multiple ways to code a solution can be a double-edge sword. Whenever possible, always strive for the optimal solution.<\/p>\n\n\n\n
14. Although that way may not be obvious at first unless you\u2019re Dutch.<\/h3>\n\n\n\n
This joking reference to Python\u2019s creator, Guido van Rossum who is Dutch. The joke being, Since Guido created Python, it\u2019s reasonable to expect he would learn a rule or see an inconspicuous solution in Python faster than any one else in general.<\/p>\n\n\n\n
15. Now is better than never.<\/h3>\n\n\n\n
Don\u2019t spend too much time procrastinating or planning too much and doing too little! Sometimes it\u2019s better to make a first version and iterate over it until it looks nice, pythonically speaking. Obviously, code that executes quickly is more better than code that executes slowly. Spend some time planning and pre-optimizing to find the best solution, but not too much!<\/p>\n\n\n\n
16. Although never is often better than *right* now.<\/h3>\n\n\n\n
This aphorism seems to be in opposition of the previous one. However, sometimes it\u2019s better to have no solution than to have a solution at all. Especially in the case when that solution can cause more harm than good to your program.<\/p>\n\n\n\n
17. If the implementation is hard to explain, it\u2019s a bad idea<\/h3>\n\n\n\n
Again, simplicity is preached. Programs need to be understandable not just by the programmer who wrote it, but also by other programmers who maintain the code. If implementing Python code is so complicated that other programmers cannot understand than it is probably a bad idea and should be avoided. If you can\u2019t say it, don\u2019t do it<\/p>\n\n\n\n
18. If the implementation is easy to explain, it may be a good idea<\/h3>\n\n\n\n
If implementing Python code seems logical, intuitive and easily explainable than it may be a good idea. Sweigart (2018) reminds us, that  just because code is easy to explain doesn\u2019t mean it isn\u2019t bad code.<\/p>\n\n\n\n
19. Namespaces are one honking great idea \u2014 let\u2019s do more of those!<\/h3>\n\n\n\n
A namespace is a collection of names and the objects that they reference. There are four distinct types of namespace that Python generates:<\/p>\n\n\n\n
locals > nonlocals > globals > builtins<\/code><\/pre>\n\n\n\n
Namespaces (and also global and local scopes) are key for preventing names in one module or scope from conflicting with names in another. According to Sweigart (2019), as great as they are, namespaces should be made only to prevent naming conflicts, and not to add needless categorization. Since \u201cZen of Python\u201d has been published, no new namespace has been introduced in Python. <\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
As you can see, the Zen of Python is just a collection of guiding principles and not necessarily rules set in stone. As you code, you should keep these principles in the back of your mind, but don\u2019t allow them to impeded or interfere with your your own coding goals. Remember, rules are meant to be broken. So long as you know why you are breaking them \u2013 you should be fine! What are your thoughts on the Zen of Python? If you have different ideas? If so, please feel free to share them in the comments below.<\/p>\n\n\n\n
\n\n\n\n
References<\/h2>\n\n\n\n
BBC News. (2011). In quotes: Apple\u2019s Steve Jobs.<\/em> BBC News.
Retrieved from: https:\/\/www.bbc.com\/news\/world-us-canada-15195448<\/p>\n\n\n\n
Hammond, J. (2017). A Brief Analysis of \u201cThe Zen of Python<\/em>.\u201d
Retrieved from: https:\/\/medium.com\/@Pythonidaer\/a-brief-analysis-of-the-zen-of-python-2bfd3b76edbf<\/p>\n\n\n\n
Jones, R. (2011). Zen of Python \u2013 Guido\u2019s Original Design Philosophy<\/em>.
Retrieved from: https:\/\/pydanny-event-notes.readthedocs.io\/en\/latest\/PyconAU2011\/zen_of_python.html<\/p>\n\n\n\n
Sweigart, A. (2018). The Zen of Python Explained. <\/em>Invent with Python Blog.
Retrieved from: https:\/\/inventwithpython.com\/blog\/2018\/08\/17\/the-zen-of-python-explained\/<\/p>\n","protected":false},"excerpt":{"rendered":"
The Zen of Python by Tim Peters, also know as PEP 20, is a collection of guiding principles.<\/p>\n","protected":false},"author":1,"featured_media":22,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4],"tags":[5,6,7,8],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/posts\/21"}],"collection":[{"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/comments?post=21"}],"version-history":[{"count":3,"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/posts\/21\/revisions"}],"predecessor-version":[{"id":130,"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/posts\/21\/revisions\/130"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/media\/22"}],"wp:attachment":[{"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/media?parent=21"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/categories?post=21"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codecrypt76.com\/index.php\/wp-json\/wp\/v2\/tags?post=21"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}