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?)
]]>1.- Beautiful is better than ugly
This basically means the fact that python is, unlike others, a language restricted by identations and arrangements; in python, identation and order really counts. That’s one of the main reasons of why python is the first programming language that is taught.
Is not the same to write
if (x in y):
s = all
Than to write
if (x in y):
s = all
The correct way is the second one.
2.- Explicit is better than implicit
In a contrast to another programming language that is implicit, JavaScript
in JS, if you type the following line
“55” + 5
JS will IMPLICITLLY take the five as string
On the other hand, in Python that line would result in an error, you have to specify first if both are srtrings or numbers
3.- Simple is better than complex
This can be explained with the cocept of debugging, of fixing your program; If you use a lot of global variables, nesting conditional and other complex methods, you may get to you goal, but if not, seeing and fixing why you didn’t reach that goal is going to be a pain in the feelings.
4.- Complex is better than complicated
To example this concept, we can use the loops for and while, check out this code:
counter = 0
while (counter < 10):
x = counter/3
counter = counter + 1
You see, this code is not complex, it is easy to get what it does, but it is too complicated, there are too many steps there; this code can be simplified with a for loop
for e in range(0,11):
x = e/3
So both codes do the same work, the diference is that one is easier to explain.
5.- Flat is better than nested
We can clear that with the conditionals. Each conditional has two paths, if the condition is met, or not. Those are the two only posibilities; now, i f you start nesting and nesting, the posibilities will grow as the powers of two, and we know it grows fast, in a four-level you will have sixteen posible paths, so things got hard. Imagine you have to debug –
6.- Sparse is better than dense
This is just a way of writting, you see, is really easier to read a code when it is well spaced and cute, rather than if it looks like the 380 bus at 7am. personally, I think that this principle has to be in every programming language because it makes it easier to read and manipulate the file itself
7.- Readibility counts
Just as the last one, it has more benefit to have a well ordene code rather than a 380 bus at 7am; it is easier to detect where have you made a mistake and how to correct it…
8.- Special cases are not special enough to break the rules
This means just one thing, everything is an object
9.- Altough practicality beats purity
10.- Errors should never pass silently
That is why python does not runs when it finds an error
11.- Unless explicitly silenced
12.- In the face of ambiguity refuse the temptation to guess
Stay stick to the status quo!, Just dont
1 + ‘1’ dont guess!
13.- There should be one obvious way to do it
This gets to an unknown to me part of python, the protocols
14.- Altough it may not be that obvious unless you are a dutch
Whuuuut?! 
15.- Now is better tha never
It’s better to fix the rpoblem ASAP because if not, debugging and functionality of further code could be negatibely affected
16.–Altough never is often better than now
Sometimes the problems won’t be resolved or would last a lot of time that is better to skipp them
17.- If the implementation it’s hard to explain, it’s a bad idea
As it’s says, if it is too complicated to explain, it is too complicated to understand, tus it may be a bad idea.
18.- If the implementation it’s easy to explain, it may be a good idea
Well, if it can be read fluently, and explained easylly, it can be a good idea, it MAY be, so don’t assume that if it can be read then it’s ok
19.- Namespaces are one hoonking great idea … let’s do more of those
it all has an order
like local variables, nonlocal variables, the evil global variables, and the built in functions, it has a good hierarchy
Coding conventions are just a set of “guidelines” that talk about the style to format a code. For example, how to correctly use braces, commas, comments, capitalization, etc. You can read a lot more of these “rules” in these webpages:
https://gcc.gnu.org/wiki/CppConventions
Since masteries 1 and 7 we’ve been using the correct style and format. If we weren’t, we could’ve just written all our codes in one line instead of multiple lines, for example, tell me how do you prefer to read a code, like this? ->
Or like this? ->
Which one is easier to read?
And know you now why there are coding conventions: to make everything look nice and easy to read.
]]>Coding conventions are just a set of “guidelines” that talk about the style to format a code. For example, how to correctly use braces, commas, comments, capitalization, etc. You can read a lot more of these “rules” in these webpages:
https://gcc.gnu.org/wiki/CppConventions
Since masteries 1 and 7 we’ve been using the correct style and format. If we weren’t, we could’ve just written all our codes in one line instead of multiple lines, for example, tell me how do you prefer to read a code, like this? ->
Or like this? ->
Which one is easier to read?
And know you now why there are coding conventions: to make everything look nice and easy to read.
]]>Here’s the Zen of Python running inside my shell.
Mastery 09 – Basic type and their use in Python
Python has 6 different basic types of data. They are:
- Integers
These are numbers that belong to all the real numbers.
- Floating point numbers
These are all the real numbers that use decimals.
- Strings
These are a set of letters, numbers or any other character. They are inbetween quotation marks (“”).
- Tuples
This is an ordered set of values with fixed number of elements, goes inbetween parentheses. - Lists
This is an ordered set of values without fixed number of elements, goes inbetween brackets.
- Dictionaries
This is a type with different elements, used to map keys to their assigned values. They keys and values can be of any type.
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!
if (a < b):
counter + =1
print (counter)
This is wrong because the IF has nothing inside it, instead it will always add 1+ to the counter because is at the same level as the IF. This is not C++ or JS where you can tell the program when your if ends with {}. The right way to do it is this:
if ( a < b):
counter += 1
print(counter)
Also here are some tips to give a standar python style to your code:
-Just do one statement per line
Please don´t do this:
def ejercicio3(diccionario): return (("Homework promedio:", sum(diccionario["homework"])/len(diccionario["homework" ])), ("Quizzes promedio:", sum(diccionario["quizzes"])/len(diccionario["quizzes"])), ("Tests promedio:", sum(diccionario["tests"])/len(diccionario["tests"])))
Yes, this is a python program that actually works. As you can see it is very hard to read and you will make others to have a bad time trying to understand what you want to do. Don´t be a smart a** and put order to your code so that everyone can understand it.
-Keep spaces between variables if necessary, just to make it more readable
-Build your functions on the top part of the code
I think that this is clear, declare your functions first and call them below. Try to declare all the functions you can on the top part and write the main program after that, this will make your code easier to read because if someone wants to follow the executuion order of your code he/she doesn´t have to look for a specific function on all the code; otherwise, he/she will know where the functions are and you will save him/her time.
-Keep your code simple
Here is an example of the last point:
a = input("Write a number"))
a = int(a)
for i in range(0,50)
if i/a % 0:
counter = counter + 1
b = counter*2
c = b+18
print (c)
This code is really simple but it can be done in less words and space, the proper way to do it is:
a = int (input("Write a number" ))
for i in range( 0 , 50 )
if (i/a) % 0:
counter += 1
print(counter*2+18)
]]>
First of all, in python the indentation does matter. Indentantion is the way that python recognize if a code block has ended. For example:
if (a < b):
counter + =1
print (counter)
This is wrong because the IF has nothing inside it, instead it will always add 1+ to the counter because is at the same level as the IF. This is not C++ or JS where you can tell the program when your if ends with {}. The right way to do it is this:
if ( a < b):
counter += 1
print(counter)
Also here are some tips to give a standar python style to your code:
-Just do one statement per line
Please don´t do this:
def ejercicio3(diccionario): return ((“Homework promedio:”, sum(diccionario[“homework”])/len(diccionario[“homework” ])), (“Quizzes promedio:”, sum(diccionario[“quizzes”])/len(diccionario[“quizzes”])), (“Tests promedio:”, sum(diccionario[“tests”])/len(diccionario[“tests”])))
Yes, this is a python program that actually works. As you can see it is very hard to read and you will make others to have a bad time trying to understand what you want to do. Don´t be a smart a** and put order to your code so that everyone can understand it.
-Keep spaces between variables if necessary, just to make it more readable
-Build your functions on the top part of the code
I think that this is clear, declare your functions first and call them below. Try to declare all the functions you can on the top part and write the main program after that, this will make your code easier to read because if someone wants to follow the executuion order of your code he/she doesn´t have to look for a specific function on all the code; otherwise, he/she will know where the functions are and you will save him/her time.
–Keep your code simple
Here is an example of the last point:
a = input(“Write a number”))
a = int(a)
for i in range(0,50)
if i/a % 0:
counter = counter + 1
b = counter*2
c = b+18
print (c)
This code is really simple but it can be done in less words and space, the proper way to do it is:
a = int (input(“Write a number” ))
for i in range( 0 , 50 )
if (i/a) % 0:
counter += 1
print(counter*2+18)
]]>
Spoiler: It’s an Easter Egg.
hey there m8
Thanks for wtching! 
C++ Conventions
Apparently the C++ coding conventions are a set of rules that guide the programming around the world. This rules are essential in order to create programs that can actually be useful in different parts of the world.
Each programming language has its own inherent rules such as any other language. Just as there are some rules besides grammar and spelling in English, in programming language there are also other rules. If you want to code properly, you mut follow this conventions.
Summing up, the coding conventions are a set of guidelines for a programm language that suggest an style, practices and ways of doing certain things when programming.
There seems to be several different conventions for any given language which I still don’t know. For example in this link (https://gcc.gnu.org/wiki/CppConventions) there is a page where you can find the different GCC G++ coding conventions that were valid until 2012-08-16. However, there are updates once in a while since programming languages evolve and become more sophisticated. Programmers should always try to be updated with the last coding convetions.
Look at an example of a simple convention about braces:
if (a > 5) { // This is K&R style } if (a > 5) { // This is ANSI C++ style } if (a > 5) { // This is GNU style }
For example, a program could as well be written using as follows:
// Using an indentation size of 2
if ( a > 5 ) { b=a; a++; }
However, the same code could be made much more readable with proper indentation:
// Using an indentation size of 2
if ( a > 5 ) {
b = a;
a++;
}
// Using an indentation size of 4
if ( a > 5 )
{
b = a;
a++;
}
I hope this little post help you to learn what coding conventions are.
References:
C++ Conventions
Apparently the C++ coding conventions are a set of rules that guide the programming around the world. This rules are essential in order to create programs that can actually be useful in different parts of the world.
Each programming language has its own inherent rules such as any other language. Just as there are some rules besides grammar and spelling in English, in programming language there are also other rules. If you want to code properly, you mut follow this conventions.
Summing up, the coding conventions are a set of guidelines for a programm language that suggest an style, practices and ways of doing certain things when programming.
There seems to be several different conventions for any given language which I still don’t know. For example in this link (https://gcc.gnu.org/wiki/CppConventions) there is a page where you can find the different GCC G++ coding conventions that were valid until 2012-08-16. However, there are updates once in a while since programming languages evolve and become more sophisticated. Programmers should always try to be updated with the last coding convetions.
Look at an example of a simple convention about braces:
if (a > 5) { // This is K&R style } if (a > 5) { // This is ANSI C++ style } if (a > 5) { // This is GNU style }
For example, a program could as well be written using as follows:
// Using an indentation size of 2
if ( a > 5 ) { b=a; a++; }
However, the same code could be made much more readable with proper indentation:
// Using an indentation size of 2
if ( a > 5 ) {
b = a;
a++;
}
// Using an indentation size of 4
if ( a > 5 )
{
b = a;
a++;
}
I hope this little post help you to learn what coding conventions are.
References: