PEP 8 - Style Guide for Python Code

gistfile1.py

# link : https://www.python.org/dev/peps/pep-0008/#code-lay-out


#  Indentation. Use 4 spaces
# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four)

# No extra indentation.
if (this_is_one_thing and
    that_is_another_thing):
    do_something()
    
if (this_is_one_thing
        and that_is_another_thing):
    do_something()
    
my_list = [
    1, 2, 3,
    4, 5, 6,
]
result = some_function_that_takes_arguments(
    'a', 'b', 'c',
    'd', 'e', 'f',
)


#  Tabs or Spaces?
# Spaces


#  Maximum Line Length
# Limit all lines to a maximum of 79 characters.


#  Example
class Rectangle(Blob):

    def __init__(self, width, height,
                 color='black', emphasis=None, highlight=0):
        if (width == 0 and height == 0 and
                color == 'red' and emphasis == 'strong' or
                highlight > 100):
            raise ValueError("sorry, you lose")
        if width == 0 and height == 0 and (color == 'red' or
                                           emphasis is None):
            raise ValueError("I don't think so -- values are %s, %s" %
                             (width, height))
        Blob.__init__(self, width, height,
                      color, emphasis, highlight)


#  Blank Lines
# Separate top-level function and class definitions with two blank lines.
# Method definitions inside a class are separated by a single blank line.
# Use blank lines in functions, sparingly, to indicate logical sections.


#  Source File Encoding
# Code in the core Python distribution should always use UTF-8 (or ASCII in Python 2).
# Files using ASCII (in Python 2) or UTF-8 (in Python 3) should not have an encoding declaration.

#  Imports
# Imports should usually be on separate lines, e.g.:

Yes: import os
     import sys

No:  import sys, os
# It's okay to say this though:

from subprocess import Popen, PIPE

# Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

# Imports should be grouped in the following order:
# 1) standard library imports
# 2) related third party imports
# 3) local application/library specific imports
# You should put a blank line between each group of imports.

# Absolute imports are recommended, as they are usually more readable and tend to be better behaved (or at least give better error messages) if the import system is incorrectly configured (such as when a directory inside a package ends up on sys.path ):

import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

# Standard library code should avoid complex package layouts and always use absolute imports.
# Implicit relative imports should never be used and have been removed in Python 3.

# When importing a class from a class-containing module, it's usually okay to spell this:
from myclass import MyClass
from foo.bar.yourclass import YourClass

# If this spelling causes local name clashes, then spell them
import myclass
import foo.bar.yourclass
# and use "myclass.MyClass" and "foo.bar.yourclass.YourClass".

# Wildcard imports ( from <module> import * ) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools.


#  String Quotes
# In Python, single-quoted strings and double-quoted strings are the same. This PEP does not make a recommendation for this. Pick a rule and stick to it. When a string contains single or double quote characters, however, use the other one to avoid backslashes in the string. It improves readability.
# For triple-quoted strings, always use double quote characters to be consistent with the docstring convention in PEP 257 .


#  Whitespace in Expressions and Statements
# Pet Peeves