What is Python. The Origins & Zen of Python

What is Python

• Python is a General purpose (we can go for any type of application development) high level (human understandable) programming language.
• Highly recommended as First programming language to learn.

• C, C++, Java …. These are statically typed languages. Means at the beginning we have to specify the type. While based on our assigned value to a variable python automatically infer the type, hence is dynamically typed language.

While Developing Python ‘Guido Van Rossam’ borrowed almost all the features from all the other programming languages.

1. Functional Programming Features from C
2. Object Oriented from C++
3. Scripting language ( Interpreted language) Features from Perl & Shell script
4. Modular programming features from Modula-3 (program is divided into modules)

Where we can use python:

1. Desktop (Standalone) Applications
2. Web Applications 🡪 DJango, Flask
3. Database Applications
4. Networking Applications
5. Games
6. Data Analysis / Data Science
7. Machine Learning
8. AI
9. IOT Applications

• For Mobile based Applications Python is not that much used and recommended.

Which Companies uses python?

1. Google
2. YouTube
3. Drop box
4. NASA……

• Python is Both Procedure Oriented and Object Oriented language. ( 1.8 onwards java is also both procedure and OOP oriented)
• Python is Extensible (we can use already existing other language programs in python also.)

Limitations of Python:

• Performance wise python is not up to the mark, However Where ever performance is very crucial, we can write that code in c, c++ language and bring that functionality in python using Python extensible feature. But the overall platform independent nature may be missed.
• Python can be a challenging language for building highly concurrent, multi-threaded applications, particularly application with many CPU-bound threads. The reason for this is that it has what is known as the global interpreter lock (GIL), a mechanism that prevents the interpreter from executing more than one python instruction at a time. The technical reason for why the GIL exists are beyond the scope of this book. While it is true that in many big data processing applications, a cluster of computers may be required to process a dataset in a reasonable amount of time, there are still situations where a single-process, multi-threaded system is desirable.This is not to say that python cannot execute truly multi-threaded, parallel code. Python C extensions that use native multi-threading (in C or C++) can run code in parallel without being impacted by the GIL, so long as they do not need to regularly interact with python objects.

Origin of Python

In an interview with Bill Venners1, Guido van Rossum said: “In the early 1980s, I worked as an implementer in a team building a language called ABC at Centrum Voor Wiskunde en Informatica (CWI), but I was frustrated with some of the concepts of ABC. So, I decided to try to design a simple scripting language that possessed some of ABC’s better properties but without its problems. So I started typing. I created a simple virtual machine, a simple parser, and a simple runtime. I made my own version of the various ABC parts that I liked. I created a basic syntax, used indentation for statement grouping instead of curly braces or begin-end blocks, and developed a small number of powerful data types: a hash table (or dictionary, as we call it), a list, strings, and numbers.”

The design of Python is greatly influenced by “ABC, a general-purpose programming language” which had been developed in the Netherland at the CWI.

What about the name?

Guido van Rossum, the creator of Python, wrote in 1996 about the origin of the name of his programming language1: “choose Python as a working title for the project, being in a slightly irreverent mood (and a big fan of Monty Python’s Flying Circus).”

Development Steps of Python

Guido Van Rossum published the first version of Python code (version 0.9.0) at alt.sources in February 1991. This release included already exception handling, functions, and the core data types of list, dict, str and others. It was also object-oriented and had a module system.

Python version 1.0 was released on January 1994. The major new features included in this release were the functional programming tools lambda, map, filter and reduce, which Guido Van Rossum never liked.

Six and a half years later on October 2000, Python 2.0 was introduced. This release included list comprehensions, a full garbage collector and it was supporting Unicode.

Python flourished for another 8 years in the versions 2.x before the next major release as Python 3.0 (also known as “Python 3000” and “Py3K”) was released. Python 3 is not backward compatible with Python 2.x. The emphasis in Python 3 had been on the removal of duplicate programming constructs and modules, thus fulfilling or coming close to fulfilling the 13th law of the Zen of Python: “There should be one — and preferably only one — obvious way to do it.”

Python versions:

1. Python 1.0 introduced in January 1994
2. Python 2.0 introduced in October 2000
3. Python 3.0 introduced in December 2008

The Guidelines (Zen) of Python

The Zen of Python is a poem written by Tim Peters in 2004. It is a collection of 20 guidelines (software principals) which guide the design of the Python language. Your Python code doesn’t necessarily have to follow these guidelines, but they’re good to keep in mind.

by using the above command we can get the complete poem.

NOTE: Mysteriously, only 19 of the guidelines are written down. Guido van Rossum reportedly said that the missing 20th aphorism is “some bizarre Tim Peters in-joke.”

Let’s decode this poem:

1. Beautiful is better than ugly

• Write codes that are nice to read and understand
• Simple expression syntax
• Be consistent
• I know this is hard: pick meaningful names

Example 1

2. Explicit is better than implicit.

you should not create confusion in the mind of the person trying to read your code.

• every time you call a function you should be naming the module explicitly. for example, if you want to use sin () function then you should specify explicitly as follow: i.e. Be explicit and revealing when it comes to variable or function naming

Example 1

this creates the confusion in the mind of the person trying to read your code, so a better approach is to use explicit naming while calling as follow:

Example 2

• Python doesn’t promote the implicit operation as follow:

hence we use following explicit type casting:

• use for loops instead of any other loop-like (i.e. while)to show better readiness as follow:

• always use the “self” to specify object a method.

• leverage the use of boolean variables

3. Simple is better than complex.

Building anything can be done using simple or complex techniques. With a simple problem, such as building a birdhouse, a simple solution is better. Building a diesel train engine, on the other hand, is a complex problem that requires complex techniques. Even if you could technically make a diesel train engine using birdhouse techniques, you probably would end up with a complicated, Rube Goldberg arrangement of birdhouse parts that wouldn’t be an ideal solution. Prefer simplicity to complexity, but know the limits of simplicity.

• To reverse a list we have to use the following in other programming languages:

instead of this, we can use the following in python: —

• do not use OOP when it’s not needed.
• Aim for lesser lines of code
• Less code == less confusion == more clarity
• python uses interactive interpreter different from java. which can be used directly.

4. Complex is better than complicated.

complex is like doing the things which are hard to understand whereas complicated is like overdoing the things.

it’s like overdoing the thing whereas following is the complex but better way to do this: —

do complex things in a “Pythonic” way, and Use SciPy and Numpy for advance science and math instead of using complicated things.

5. 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. It’s okay to have code in just one top-layer module or class instead of splitting up across multiple submodules or subclasses. If you make packages and modules that require code like import spam.eggs.bacon.ham.foo.bar, then you’re making your code too complicated.

6. Sparse is better than dense.

• don’t try to stick too much code on one line.

Example:

• Be loosely coupled

7. Readability counts.

While strcmp() may obviously mean the “string compare” function to someone who has been programming in C since the 1970s, modern computers have enough memory to write out the full function name. Don’t drop vowels from your names or write overly terse code. Code is read more often than it’s written, so explicit, readable code is more important than terse, undocumented code.

The easy one: compare C and Python. The readability of python is much more good than C language.

And what about indentation? Indented code is more readable. Thus, in Python it’s mandatory.

Example:

• use more readable variable names, each variables name should show its purpose.

• use inline documentation.

• Use Consistent whitespace.
• Code for humans.
• Whitespace for block structures

• Use Minimal Punctuation

8–9. Special cases aren’t special enough to break the rules. Although practicality beats purity.

These two aphorisms, which come as a set, contradict each other. Programming is full of “best practices” that programmers should strive for in their code. Skirting these practices for a quick hack may be tempting, but can lead to a rat’s nest of inconsistent, unreadable code. However, bending over backward to adhere to rules can result in highly-abstract, unreadable code. The Java programming language’s attempt to fit all code to its object-oriented paradigm often results in lots of boilerplate code for even the smallest program. Walking the line between these two aphorisms becomes easier with experience. And in time, you’ll not only learn the rules but also learn when to break them.

a. Special cases aren’t special enough to break the rules.

In Java, primitive data types are considered special cases, whereas in python Everything is an object.

in any other language, it would return True.

b. Since here practicality beats purity therefore,

Python has a multi-model approach. It is:

• Procedural
• OOP
• Functional

In Python Methods and functions differ by scope.

10–11. Errors should never pass silently. Unless explicitly silenced.

Just because programmers often ignore error messages doesn’t mean the program should stop emitting them. Silent errors can happen when functions return error codes or None instead of raising exceptions. These two aphorisms tell us that it’s better for a program to fail fast and crash than to silence the error and continue running the program. The bugs that inevitably happen later on will be harder to debug since they are far removed from the original cause.

Errors should never pass silently

Though you can always choose to explicitly ignore the errors your programs cause, just be sure you are making the conscious choice to do so.

Unless Explicitly silenced

12. In the face of ambiguity, refuse the temptation to guess.

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.

13. There should be one — and preferably only one — obvious way to do it.

This is a broadside against the Perl programming language’s motto, “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.

How many ways could you provide to “iterate over a sequence in C++ ?”

Iterating over an array with integers or pointers; iterating over STL vectors with various kinds of iterators … etc. hence, If you want to be proficient in C++ (and be able to read other people’s code), you must learn them all.

In Python you must learn only one:

14. Although that way may not be obvious at first unless you’re Dutch.

This line is a joke. Guido van Rossum, the creator and BDFL (Benevolent Dictator for Life) of Python, is Dutch

15- 16. 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.

In the first example, an exception will bump you out of the codeblock before the file can be closed. In the second, python will politely handle this for you with context managers. You could, of course, fix the first case by using try: and finally: blocks, but beautiful is better than ugly.

17- 18. 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.

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.

19. Namespaces are one honking great idea — let’s do more of those!

Namespaces (and also global and local scopes) are key for preventing names in one module or scope from conflicting with names in another. But also remember that flat is better than nested: As great as they are, namespaces should be made only to prevent naming conflicts, and not to add needless categorization.