Introduction :
Python was created keeping 20 principles in mind:
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!
When programming in python we need to give higher focus to readability, thus pythonic code creation is good to learn.
This style guide is a list of do’s and don't for Python programs. It follows Python Enhancement Proposals (PEP8) .
 
 
DocString
Every python file in the project must have a docstring1
Source file encoding
Code in the core Python distribution should always use UTF-8 (or ASCII in Python 2). A comment or docstring needs to mention an author name and encoding at the start of the source code.
Indentation
Use 4 spaces per indentation level.  In python spaces are preferred indentation method. Python 3 doesn't allow mixing tabs and spaces for indentation that is why one need to be carefule.
Maximum line length
It is good to keep 79 character length of a line in python code, so that one can see see whole expression without scrolling horizontally as well to files can be compared at the same time.
For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.
Blank lines
Surround top-level function and class definitions with two blank lines.
Method definitions inside a class are surrounded by a single blank line.
Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations).
Use blank lines in functions, sparingly, to indicate logical sections.
Imports
Imports should usually be on separate lines not all packages should be imported in same line.
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
It is good to group the similar type of libraries together the order should be:
1. standard library import
2. related third party import
3. local library/application file import
Absolute imports are highly recommended as they explicitly help to avoid over rights.
wildcard imports should be avoided as they are unclear and unreadable (unless you are overwriting an original package implementation).
 Whitespaces
 
Note:
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important.
However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!
In particular: do not break backwards compatibility just to comply with this PEP!
Python tools for code complexity and static code check