PEP阅读摘要:二

• PEP13 – Python Language Governance

  The steering council is a 5-person committee cannot modify this PEP, or affect the membership of the core team, except via the mechanisms specified in this PEP.

  The council should look for ways to use these powers as little as possible. Instead of voting, it’s better to seek consensus. Instead of ruling on individual PEPs, it;s better to define a standard process for PEP decision making. It’s better to establish a Code of Conduct committee than to rule on individual cases.

• PEP20 – The Zen of Python

• PEP101 – Doing Python Releases 101

  This PEP attempts to collect, in one place, all the steps needed to make a Python release， which is a thrilling and crazy process.

• PEP247 – API for Cryptographic Hash Functions

  There are several different modules available that implement cryptographic hashing algorithms such as MD5 or SHA. This document specifies a standard API for such algotithms, to make it easier to switch between different implementations.

  All hasing modules should present the same interface. Additional methods or variables can be added, but those described in this document should always be present.

• PEP248 – Python Database API Specification v1.0

  This API has been defined to encourage similarity between the Python modules that are used to access databases. By doing this, we hope to achieve a consistency leading to more easily understood modules, code that is generally more portable across databases, and a broader reach of database connectivity from Python.

• PEP249 – Python Database API Specification v2.0

• PEP257 – Docstring Conventions

  This PEP documents the semantic and conventions associated with Python docstrings.

  The aim of this PEP is to stanardize the high-level structure of docstrings: what they should contain, and how to say it (without touching on any markup syntax within docstrings). The PEP contains conventions, not laws or syntax.

  • what is a Docstring

    A docstring is a string literal that occurs as the first statement in a module, function, class, or method definition. Such a docstring becomes the __doc__special attribute of the object.

    All modules should normally have docstings, and all functions and classes exported by a module should also have docstrings.

    Public methods(including the __init__ consructor) should also have docstrings.

    A package may be documented in the module docstring of the __init__.py file in the package directory.

  • always use """triple double quotes""" around docstrings

  • there are two forms of docstrings: one-liners and multi-line docstrings

  • The docstring is a phrase ending in a period. It prescribes the function or method;s effect as a command(“Do this”, “Return that”), not as a description; e.g. don’t write “Returns the pathname…”

  • Multi-line docstrings consist of a summary line just like a one-line docstring, followed by a blank line, followed by a more elaborate description. The summary line may be used by automatic indexing tools; it is important that it fits on one line and is separated from the rest of the docstring by a blank line. The summary line may be on the same line as the opening quotes or on the next line. The entire docstring is endented the same as the quotes at its first line.

    def complex(real=0.0, imag=0.0):
     """Form a complex number.
    
     Keyword arguments:
     real -- the real part (default 0.0)
     imag -- the imaginary part (default 0.0)
     """
     if imag == 0.0 and real == 0.0:
         return complex_zero
     ...
    

  • The docstring in this example contains two newline characters and is therefore 3 lines long. The first and last lines are blank:

    def foo():
     """
     This is the second line of the docstring.
     """
    # to illustrate
    >>> print(repr(foo.__doc___))
    '\n    This is the second line of the docstring.\n    '
    >>> trim(foo.__doc__)
    'This is the second line of the docstring.'