The Zen of python

The next assignment, how I understood it, is to figure out what the Zen of Python is, how you have to open it and my interpretation of the rules.

So, to give an answer on the first question I just asked Google (cause everything, not only help with Python, that you want to figure out, start with asking Google). Google is your best friend with figuring stuff out. So when I asked Google I got this site. Unfortunately, it gave more the answer to my second question so let’s answer that first. To open the zen of Python you have to type: print this (see my script). If your run your script after that, it will give the content of the zen in your shell:

The zen of Python is written by Tim Peeters. He made it as guiding principles for writing Python language. It consists of 20 guidelines, 19 of them are filled in by himself and the 20th rule was meant to fill in by Guido van Rossum, the original writer of the Python language, but he never filled in the last rule.

And now over to my interpretation of the rules. The first 6 rules consists information about what is better according to Tim:

1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.

In my opinion, every person is meaning something different when they make such rules, but it is a good guideline. The first six rules are mostly about how your code must appear and what it has to look like. Timo maybe wanted to achieve people to think better about what they are writing. It has to be good structured to recognize it afterwards, that way it has to beautiful, explicit, simple, not nested and sparse. If you write it like this, your code stays clear and understandable for other people and yourself at a later time. This is important for Python, because his popularity is partly a result of his clearness.

The seventh rule “Readability counts” has also everything to do with how important it is to write your code clear. The explanation therefore is that a code is more often is being read then written.

The eight and ninth rule are “Special cases aren’t special enough to break the rules. Although practicality beats purity.” This is actually a contradiction, because the second sentence contradicts the first one.

The tenth and eleventh rule “Errors should never pass silently. Unless explicitly silenced.” This rule is about errors, it is way much easier to recognize your error close by, so don’t let them pas silently and always fix the errors how small they are.

The twelfth rule “In the face of ambiguity, refuse the temptation to guess.” I would think that this rule is about that you have to think about what you’re doing and if something in your code happens, you have to know why it happens. Don’t only guess and be happy if it is working, you always need to critical think about if it is really working and why and that it is not only a coincidence.

The thirteenth rule “There should be one—and preferably only one—obvious way to do it. “ prefers only one obvious way to do it, because that makes it a lot more easy for everybody. In the case that there is only one way, everybody only has to know that one way. That prevents unnecessary time of learning.

I don’t really understand the fourteenth rule “Although that way may not be obvious at first unless you’re Dutch.” even when I am Dutch. So yeah, use your own interpretation about Dutch people in this rule. Probably it has something to do with the fact that the maker of Python, Guido van Rossum, is Dutch.

The fifteenth and sixteenth rule are “Now is better than never. Although never is often better than *right* now.” With my interpretation, this rule has something to do with writing and finishing the code that your are writing. Right now is not always possible, because you need time to think about what you are writing and it can be frustrating if you really want to finish it right now. But don’t wait to long, because you still need to know what you are doing and trying.

The seventeenth and eighteenth rule “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.” is also about making your code so easy as possible, most of the time there must be an easy way to achieve what you want. The easiest way is always the best, because it is good if other persons understand your code.

The nineteenth and last rule is “Namespaces are one honking great idea — let’s do more of those!”. Use them, because it gives your code a clearer overview.

I agree with all this rule, it is very important to make your code clearer and readable for everyone. Hopefully you liked my view on these rules!