Python Enhancement Proposal.
PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment.
pip install pep8
pycodestyle ...warnings.warn(method.py:8:1: E302 expected 2 blank lines, found 1method.py:11:5: E301 expected 1 blank line, found 0
其他 Python 静态代码检测工具：pyflakes, pylint
# Wrong:# operators sit far away from their operandsincome = (gross_wages +taxable_interest +(dividends - qualified_dividends) -ira_deduction -student_loan_interest)# Correct:# easy to match operators with operandsincome = (gross_wages+ taxable_interest+ (dividends - qualified_dividends)- ira_deduction- student_loan_interest)
Imports should be grouped in the following order:
Standard library imports.
Related third party imports.
Local application/library specific imports.
You should put a blank line between each group of imports.
模块级 dunder names
Module level "dunders" (i.e. names with two leading and two trailing underscores) such as
__version__, etc. should be placed after the module docstring but before any import statements except
from __future__ imports. Python mandates that future-imports must appear in the module before any other code except docstrings:
"""This is the example module.This module does stuff."""from __future__ import barry_as_FLUFL__all__ = ['a', 'b', 'c']__version__ = '0.1'__author__ = 'Cardinal Biggles'import osimport sys
# Correct:foo = (0,)# Wrong:bar = (0, )
# Correct:i = i + 1submitted += 1x = x*2 - 1hypot2 = x*x + y*yc = (a+b) * (a-b)# Wrong:i=i+1submitted +=1x = x * 2 - 1hypot2 = x * x + y * yc = (a + b) * (a - b)
# Correct:def complex(real, imag=0.0):return magic(r=real, i=imag)# Wrong:def complex(real, imag = 0.0):return magic(r = real, i = imag)
# Correct:FILES = ['setup.cfg','tox.ini', # 可能在后期进行扩展]initialize(FILES,error=True,)# Wrong:FILES = ['setup.cfg', 'tox.ini',]initialize(FILES, error=True,)
Author: Guido van Rossum, Nick Coghlan
with statement in Python is used in exception handling to make the code cleaner and much more readable. It simplifies the management of common resources like file streams.
# file handling# 1) without using with statementfile = open('file_path', 'w')file.write('hello world !')file.close()# 2) without using with statementfile = open('file_path', 'w')try:file.write('hello world')finally:file.close()# using with statementwith open('file_path', 'w') as file:file.write('hello world !')
Notice that unlike the first two implementations, there is no need to call
file.close() when using
with statement. The
with statement itself ensures proper acquisition and release of resources. An exception during the
file.write() call in the first implementation can prevent the file from closing properly which may introduce several bugs in the code, i.e. many changes in files do not go into effect until the file is properly closed.
The second approach in the above example takes care of all the exceptions but using the
with statement makes the code compact and much more readable. Thus,
with statement helps avoiding bugs and leaks by ensuring that a resource is properly released when the code using the resource is completely executed. The
with statement is popularly used with file streams, as shown above and with Locks, sockets, subprocesses and telnets etc.
In Python 2.5, the new syntax will only be recognized if a future statement is present:
from __future__ import with_statement
This will make both 'with' and 'as' keywords. Without the future statement, using 'with' or 'as' as an identifier will cause a Warning to be issued to stderr.
In Python 2.6, the new syntax will always be recognized; 'with' and 'as' are always keywords.
PEP 440 introduces a version format that every Python package, and ideally everyapplication, should follow.
"Projects" are software components that are made available for integration. Projects include Python libraries, frameworks, scripts, plugins, applications, collections of data or other resources, and various combinations thereof. Public Python projects are typically registered on the Python Package Index.
"Releases" are uniquely identified snapshots of a project.
"Distributions" are the packaged files which are used to publish and distribute a release.