The Zen of Python
The Zen of Python is an Interesting easter egg in Python.
Originally written by Tim Peters in 2004, it as an informational entry number 20 in Python Enhancement Proposals
You can find it by entering the statement “import this”
I shall comment on a few of them because I think they are open to interpretation.
The Zen of Python
Beautiful is better than ugly.
-Beauty is subjective and ugly is too extreme, so whatever floats your boat is fine really. When I say ugly is too extreme I mean that when something is obviously ugly you can make it look better while improving its functionality.
Explicit is better than implicit.
–
Simple is better than complex.
-when something. Is simple it is also easily knowable.
Complex is better than complicated.
–
Flat is better than nested.
-I read that some people may get confused and think of the wrong kind of nesting, not the bird kind of course. It refers to block nesting, for a lot of reasons it usually seen in a negative light since it leads to complex code.
Read more here:
https://en.wikipedia.org/wiki/Cyclomatic_complexity
Namespaces are great as they help organize code to reduce complexity.
These 2 are complimentary as they are both about reducing code complexity.
Sparse is better than dense.
-this may refer to a general minimalism. Minimizing your depth of nesting of control structures, the number of lines or length of code, token count, character count, parameters, variables, looping instructions and conditionals. Minimizing at our level of programming may be risky for example, having long names for variables can actually be helpful so you just have to be careful. ,m
Readability counts.
-Some may say this is what makes organizations choose Python but who knows.
Special cases aren’t special enough to break the rules.
-Everything is an object
Although practicality beats purity.
-rules can be broken if you need to. For example circular imports:
They’re not always a bad thing. In many cases you only have to import the module not from the module.
Errors should never pass silently.
-silent errors can wreck you and make you blame the users.
Unless explicitly silenced.
-Errors can be addressed in creative ways.
In the face of ambiguity, refuse the temptation to guess.
-self explanatory I think.
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.
– Guido needs more credit.
Now is better than never.
-Just don’t wait, it’s not worth it.
Although never is often better than *right* now.
–
If the implementation is hard to explain, it’s a bad idea.
-better avoid it than do something without knowing.
If the implementation is easy to explain, it may be a good idea.
-you should also avoid extremely simple stuff.
Namespaces are one honking great idea — let’s do more of those!
–
(Where is number 20? Is it a formatting character? Maybe a new Line?)
Mastery08 by 5nbpppkkyj is licensed under a Creative Commons Attribution 4.0 International License.