Python Introduction
Prerequisite :
Installing python
-
As an introduction to python, We will talk about Easter Eggs (of python for sure).
Hello World
The famous hello world program, python has a library that does that. Enter “import __hello__” and see the magic!
Antigravity
Forget about the hello world library, enter this “import antigravity”!
The Zen of Python
Now let’s talk seriously, first of all enter “import this” into the interactive shell.
The output is “The Zen of Python”,a poem written by Tim Peters (American Software Developer and a huge contributer to this language) which explains the philosophy of this holy langauge. Here is a brief analysis of it :
- Beautiful is better than ugly. - Instead of && or || as logical operators, python uses and || or . **EASY PEASY**
- Explicit is better than implicit. “This aphorism is self-explanatory,” that would be a terrible explanation for any aphorism. Similarly, that’s what python do; verbose and explicit. We will talk about this later in upcoming posts.
- Simple is better than complex. Complex is better than complicated. - Steve Jobs stated once that “simple can be harder than complex”. And that’s true. Requires a lot of hard work to get your thinking clean, to come up with a simple solution. But a simple solution is always better than a complex one. We need to apply those words in our code later.
- Flat is better than nested. - Programmers love to organize things into categories, especially categories that contain subcategories which contain other sub-subcategories. These hierarchies often don’t add organization so much as they add bureaucracy.
- Sparse is better than dense. - Writing some hard to read code may impress your friends but it’ll infuriate your coworkers who have to try to understand it. Keep it Sparce!
-
Readability counts. - It’s 2020 guys, we have enough memory to write out the full function name. **FUCK C LANGUAGE FUNCTION NAMES**
- Special cases aren’t special enough to break the rules although practicality beats purity. - We will talk about this one later, it’s so special.
- Errors should never pass silently, unless explicitly silenced. — Never let errors, which may occur, confuse the reader. This may easily be resolved by printing a string when an error occurs.
- In the face of ambiguity, refuse the temptation to guess. – Computers have made humans superstitious: To exorcise the demons in our computers we perform the sacred ritual of turning them off and then on. Supposedly this will fix any mysterious problem. However, computers are not magic. If your code isn’t working, there is a reason and only careful, critical thinking will solve it. Refuse the temptation to blindly try solutions until something seems to work; often you have merely masked the problem rather than solved it.
- There should be one—and preferably only one—obvious way to do it.- This is a broadside against the Perl programming language’s slogan, “There’s more than one way to do it!” It turns out that having three or four different ways to write code that does the same thing is a double-edged sword: you have flexibility in how you write code, but now you have to learn every possible way it could have been written in order to read it. This flexibility isn’t worth the 3x or 4x effort needed to learn a programming language.
- 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.
- Now is better than never. Although never is often better than right now. These two aphorisms tell us that code that hangs or gets caught in infinite loops is obviously worse than code that doesn’t. However, it’s almost certainly better to wait for your program to finish than to have it finish too early with incorrect results.
- 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. - Python strives to make the programmer’s job easier rather than accommodate the computer so a program runs faster. And programs need to be understandable not just by the programmer who wrote it, but also by other programmers who maintain the code. These two aphorisms remind us that if “high-performance” code is so complicated as to be impossible for programmers to understand and debug, then it’s bad code. But alas, just because it’s easy to explain a program’s code to someone else doesn’t mean it isn’t bad code. Programming is hard.
- 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.
It’s enough for today, don’t forget to come back tomorrow ! Прощай <3
Referrence : Official python PEP