Error Codes


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
D106 Missing docstring in public nested class
D107 Missing docstring in __init__
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 Deprecated: 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
D415 First line should end with a period, question mark, or exclamation point
D416 Section name should end with a colon
D417 Missing argument descriptions in the docstring
D418 Function/ Method decorated with @overload shouldn’t contain a docstring
D419 Docstring is empty

Default conventions

Not all error codes are checked for by default. There are three conventions that may be used by pydocstyle: pep257, numpy and google.

The pep257 convention (specified in PEP257), which is enabled by default in pydocstyle, checks for all of the above errors except for D203, D212, D213, D214, D215, D404, D405, D406, D407, D408, D409, D410, D411, D413, D415, D416 and D417.

The numpy convention added in v2.0.0 supports the numpydoc docstring standard. This checks all of the errors except for D107, D203, D212, D213, D402, D413, D415, D416, and D417.

The google convention added in v4.0.0 supports the Google Python Style Guide. This checks for all the errors except D203, D204, D213, D215, D400, D401, D404, D406, D407, D408, D409 and D413.

These conventions may be specified using --convention=<name> when running pydocstyle from the command line or by specifying the convention in a configuration file. See the Usage section for more details.


It makes no sense to check the same docstring for both numpy and google conventions. Therefore, if we successfully detect that a docstring is in the numpy style, we don’t check it for google.

The reason numpy style takes precedence over google is that the heuristics of detecting it are better, and we don’t want to enforce users to provide external hints to pydocstyle in order to let it know which style docstrings are written in.


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 start with a single or double underscore.

    1. Note, names that start and end with a double underscore are public (e.g.

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.

Note, a module’s parent is recursively checked upward until we reach a directory in sys.path to avoid considering the complete filepath of a module. For example, consider the module /_foo/bar/ If PYTHONPATH is set to /, then is private. If PYTHONPATH is set to /_foo/, then is public.

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 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.