PYDOCSTYLE(1)

NAME
pydocstyle - pydocstyle Documentation

pydocstyle is a static analysis tool for checking compliance with Python docstring conventions.

pydocstyle supports most of PEP 257 out of the box, but it should not be considered a reference implementation.

pydocstyle supports Python 2.7, 3.3, 3.4, 3.5 and pypy.

    1.  Install

                    pip install pydocstyle

    2.  Run

                    $ pydocstyle test.py
                    test.py:18 in private nested class `meta`:
                            D101: Docstring missing
                    test.py:27 in public function `get_user`:
                        D300: Use """triple double quotes""" (found '''-quotes)
                    test:75 in public function `init_database`:
                        D201: No blank lines allowed before function docstring (found 1)
                    ...

    3.  Fix your code :)

Contents:

USAGE

  Installation

Use pip or easy_install:

        pip install pydocstyle

Alternatively, you can use pydocstyle.py source file directly - it is self-contained.

  Command Line Interface

  Usage

        Usage: pydocstyle [options] [<file|dir>...]

        Options:
          --version             show program's version number and exit
          -h, --help            show this help message and exit
          -e, --explain         show explanation of each error
          -s, --source          show source for each error
          -d, --debug           print debug information
          -v, --verbose         print status information
          --count               print total number of errors to stdout
          --config=<path>       use given config file and disable config discovery
          --select=<codes>      choose the basic list of checked errors by specifying
                                which errors to check for (with a list of comma-
                                separated error codes or prefixes). for example:
                                --select=D101,D2
          --ignore=<codes>      choose the basic list of checked errors by specifying
                                which errors to ignore (with a list of comma-separated
                                error codes or prefixes). for example:
                                --ignore=D101,D2
          --convention=<name>   choose the basic list of checked errors by specifying
                                an existing convention. Possible conventions: pep257,
                                numpy
          --add-select=<codes>  amend the list of errors to check for by specifying
                                more error codes to check.
          --add-ignore=<codes>  amend the list of errors to check for by specifying
                                more error codes to ignore.
          --match=<pattern>     check only files that exactly match <pattern> regular
                                expression; default is --match='(?!test_).*\.py' which
                                matches files that don't start with 'test_' but end
                                with '.py'
          --match-dir=<pattern>
                                search only dirs that exactly match <pattern> regular
                                expression; default is --match-dir='[^\.].*', which
                                matches all dirs that don't start with a dot
          --ignore-decorators=<decorators>
                                ignore any functions or methods that are decorated by
                                a function with a name fitting the <decorators>
                                regular expression; default is --ignore-decorators=''
                                which does not ignore any decorated functions.

NOTE:
        When using any of the --select, --ignore, --add-select, or --add-ignore command line flags, it is possible to pass a prefix for an error code. It will be expanded so that any code begining with that prefix will match. For example, running the command pydocstyle --ignore=D4 will ignore all docstring content issues as their error codes begining with "D4" (i.e. D400, D401, D402, D403, and D404).

  Return Code
0 | Success - no violations
1 | Some code violations were found
2 | Illegal usage - see error message

  Configuration Files

pydocstyle supports ini-like configuration files. In order for pydocstyle to use it, it must be named one of the following options, and have a [pydocstyle] section.

    •   setup.cfg

    •   tox.ini

    •   .pydocstyle

    •   .pydocstyle.ini

    •   .pydocstylerc

    •   .pydocstylerc.ini

When searching for a configuration file, pydocstyle looks for one of the file specified above in that exact order. If a configuration file was not found, it keeps looking for one up the directory tree until one is found or uses the default configuration.

NOTE:
        For backwards compatibility purposes, pydocstyle supports configuration files named .pep257, as well as section header [pep257]. However, these are considered deprecated and support will be removed in the next major version.

  Available Options

Not all configuration options are available in the configuration files. Available options are:

    •   convention

    •   select

    •   ignore

    •   add_select

    •   add_ignore

    •   match

    •   match_dir

    •   ignore_decorators

See the Usage section for more information.

  Inheritance

By default, when finding a configuration file, pydocstyle tries to inherit the parent directory's configuration and merge them to the local ones.

The merge process is as follows:

    •   If one of select, ignore or convention was specified in the child configuration - Ignores the parent configuration and set the new error codes to check. Otherwise, simply copies the parent checked error codes.

    •   If add-ignore or add-select were specified, adds or removes the specified error codes from the checked error codes list.

    •   If match or match-dir were specified - use them. Otherwise, use the parent's.

In order to disable this (useful for configuration files located in your repo's root), simply add inherit=false to your configuration file.

NOTE:
        If any of select, ignore or convention were specified in the CLI, the configuration files will take no part in choosing which error codes will be checked. match and match-dir will still take effect.

  Example

        [pydocstyle]
        inherit = false
        ignore = D100,D203,D405
        match = *.py

  In-file configuration

pydocstyle supports inline commenting to skip specific checks on specific functions or methods. The supported comments that can be added are:

    1.  "# noqa" skips all checks.

    2.  "# noqa: D102,D203" can be used to skip specific checks. Note that this is compatible with skips from flake8, e.g. # noqa: D102,E501,D203.

For example, this will skip the check for a period at the end of a function docstring:

        >>> def bad_function():  # noqa: D400
        ...     """Omit a period in the docstring as an exception"""
        ...     pass

ERROR CODES

  Grouping
Missing Docstrings
D100 | Missing docstring in public module
D101 | Missing docstring in public class
D102 | Missing docstring in public method
D103 | Missing docstring in public function
D104 | Missing docstring in public package
D105 | Missing docstring in magic method
Whitespace Issues
D200 | One-line docstring should fit on one line with quotes
D201 | No blank lines allowed before function docstring
D202 | No blank lines allowed after function docstring
D203 | 1 blank line required before class docstring
D204 | 1 blank line required after class docstring
D205 | 1 blank line required between summary line and description
D206 | Docstring should be indented with spaces, not tabs
D207 | Docstring is under-indented
D208 | Docstring is over-indented
D209 | Multi-line docstring closing quotes should be on a separate line
D210 | No whitespaces allowed surrounding docstring text
D211 | No blank lines allowed before class docstring
D212 | Multi-line docstring summary should start at the first line
D213 | Multi-line docstring summary should start at the second line
D214 | Section is over-indented
D215 | Section underline is over-indented
Quotes Issues
D300 | Use """triple double quotes"""
D301 | Use r""" if any backslashes in a docstring
D302 | Use u""" for Unicode docstrings
Docstring Content Issues
D400 | First line should end with a period
D401 | First line should be in imperative mood
D401 | First line should be in imperative mood; try rephrasing
D402 | First line should not be the function's "signature"
D403 | First word of the first line should be properly capitalized
D404 | First word of the docstring should not be This
D405 | Section name should be properly capitalized
D406 | Section name should end with a newline
D407 | Missing dashed underline after section
D408 | Section underline should be in the line following the section's name
D409 | Section underline should match the length of its name
D410 | Missing blank line after section
D411 | Missing blank line before section
D412 | No blank lines allowed between a section header and its content
D413 | Missing blank line after last section
D414 | Section has no content

  Default Checks

Not all error codes are checked for by default. The default behavior is to check only error codes that are part of the PEP257 official convention.

All of the above error codes are checked for by default except for D203, D212, D213 and D404.

  Publicity

The D1xx group of errors deals with missing docstring in public constructs: modules, classes, methods, etc. It is important to note how publicity is determined and what its effects are.

  How publicity is determined

Publicity for all constructs is determined as follows: a construct is considered public if -

    1.  Its immediate parent is public and

    2.  Its name does not contain a single leading underscore.

A construct's immediate parent is the construct that contains it. For example, a method's parent is a class object. A class' parent is usually a module, but might also be a function, method, etc. A module can either have no parent, or it can have a parent that is a package.

In order for a construct to be considered public, its immediate parent must also be public. Since this definition is recursive, it means that all of its parents need to be public. The corollary is that if a construct is considered private, then all of its descendants are also considered private. For example, a class called _Foo is considered private. A method bar in _Foo is also considered private since its parent is a private class, even though its name does not begin with a single underscore.

Modules are parsed to look if __all__ is defined. If so, only those top level constructs are considered public. The parser looks for __all__ defined as a literal list or tuple. As the parser doesn't execute the module, any mutation of __all__ will not be considered.

  How publicity affects error reports

The immediate effect of a construct being determined as private is that no D1xx errors will be reported for it (or its children, as the previous section explains). A private method, for instance, will not generate a D102 error, even if it has no docstring.

However, it is important to note that while docstring are optional for private construct, they are still required to adhere to your style guide. So if a private module _foo.py does not have a docstring, it will not generate a D100 error, but if it does have a docstring, that docstring might generate other errors.

pydocstyle is a rename and continuation of pep257, a project created by Vladimir Keleshev.

Maintained by Amir Rachum.

AUTHOR
Amir Rachum

COPYRIGHT
2017, Amir Rachum