PYDOCSTYLE(1)
π PYDOCSTYLE(1) π
okay bestie, welcome to the pydocstyle manual page, this is your girl explaining the whole thing top to bottom, no skips, no cuts π
β¨ NAME β¨
pydocstyle β the pydocstyle Documentation, like, the whole thing πΈ
pydocstyle is a static analysis tool for checking compliance with Python docstring conventions. yes queen, it reads your code so you don't have to π
pydocstyle supports most of PEP 257 out of the box, but it should not be considered a reference implementation. (like, it's giving "very good", not "the actual law" π«Ά)
pydocstyle supports Python 3.7 through 3.11.
Although pydocstyle is tries to be compatible with Python 3.6, it is not tested. π
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. iconic honestly β¨
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
--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 --match, --match-dir or --ignore-decorators consider
whether you should use a single quote (') or a double quote ("),
depending on your OS, Shell, etc.
Error Check Options:
Only one of --select, --ignore or --convention can be specified. If
none is specified, defaults to `--convention=pep257`. These three
options select the "basic list" of error codes to check. If you wish
to change that list (for example, if you selected a known convention
but wish to ignore a specific error from it or add a new one) you can
use `--add-[ignore/select]` in order to do so.
--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 out of all of the available
error codes (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, google.
--add-select=<codes>
add extra error codes to check to the basic list of
errors previously set by --select, --ignore or
--convention.
--add-ignore=<codes>
ignore extra error codes by removing them from the
basic list previously set by --select, --ignore or
--convention.
NOTE: When using any of the--select,--ignore,--add-select, or--add-ignorecommand line flags, it is possible to pass a prefix for an error code. It will be expanded so that any code beginning with that prefix will match. For example, running the commandpydocstyle --ignore=D4will ignore all docstring content issues as their error codes beginning with "D4" (i.e.D400,D401,D402,D403, andD404). π
Return Code π’
0β Success β no violations π1β Some code violations were found π¬2β Illegal usage β see error message π
Configuration Files π
pydocstyle supports ini-like and toml configuration files. In order for pydocstyle to use a configuration file automatically, it must be named one of the following options.
setup.cfgtox.ini.pydocstyle.pydocstyle.ini.pydocstylerc.pydocstylerc.inipyproject.toml
When searching for a configuration file, pydocstyle looks for one of the file specified above in that exact order. ini-like configuration files must have a [pydocstyle] section while toml configuration files must have a [tool.pydocstyle] section. If a configuration file was not found, pydocstyle keeps looking for one up the directory tree until one is found or uses the default configuration. it's literally climbing the tree bestie π³
NOTE: toml configuration file support is only enabled if the toml python package is installed. You can ensure that this is the case by installing the pydocstyle[toml] optional dependency.
NOTE: For backwards compatibility purposes,pydocstylesupports 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. so like, don't get attached π
Available Options βοΈ
Not all configuration options are available in the configuration files. Available options are:
conventionselectignoreadd_selectadd_ignorematchmatch_dirignore_decoratorsproperty_decoratorsignore_self_only_init
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,ignoreorconventionwas 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-ignoreoradd-selectwere specified, adds or removes the specified error codes from the checked error codes list. - If
matchormatch-dirwere 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 ofselect,ignoreorconventionwere specified in the CLI, the configuration files will take no part in choosing which error codes will be checked.matchandmatch-dirwill 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:
"# noqa"skips all checks."# 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
Usage with the pre-commit git hooks framework πͺ
pydocstyle can be included as a hook for pre-commit. The easiest way to get started is to add this configuration to your .pre-commit-config.yaml:
- repo: https://github.com/pycqa/pydocstyle
rev: 0.0.0 # pick a git hash / tag to point to
hooks:
- id: pydocstyle
See the pre-commit docs for how to customize this configuration.
Checked-in python files will be passed as positional arguments so no need to use --match=*.py. You can also use command line arguments instead of configuration files to achieve the same effect with less files.
- id: pydocstyle
args:
- --ignore=D100,D203,D405
# or multiline
- |-
--select=
D101,
D2
π ERROR CODES π
okay bestie, this is the part where pydocstyle tells you exactly which vibe crime you committed. every message has a code, and every code lives in a little squad. no cap, the codes are grouped by what kind of mess you made π«Ά
β¨ Grouping β¨
the codes roll up into four families: docstrings that straight-up ghosted you, whitespace chaos, quote drama, and content glow-ups. let's go code by code, iykyk πΈ
π Missing Docstrings π
not a single docstring in sight. it's giving mystery but not the cute kind π
D100β Missing docstring in public moduleD101β Missing docstring in public classD102β Missing docstring in public methodD103β Missing docstring in public functionD104β Missing docstring in public packageD105β Missing docstring in magic methodD106β Missing docstring in public nested classD107β Missing docstring in__init__
π Whitespace Issues π
the spacing is not spacing-ing. lowkey these are all about blank lines and indentation being just right π
D200β One-line docstring should fit on one line with quotesD201β No blank lines allowed before function docstringD202β No blank lines allowed after function docstringD203β 1 blank line required before class docstringD204β 1 blank line required after class docstringD205β 1 blank line required between summary line and descriptionD206β Docstring should be indented with spaces, not tabsD207β Docstring is under-indentedD208β Docstring is over-indentedD209β Multi-line docstring closing quotes should be on a separate lineD210β No whitespaces allowed surrounding docstring textD211β No blank lines allowed before class docstringD212β Multi-line docstring summary should start at the first lineD213β Multi-line docstring summary should start at the second lineD214β Section is over-indentedD215β Section underline is over-indented
π¦ Quotes Issues π¦
the way your quotes are arranged is the whole personality of the docstring fr fr
D300β Use"""triple double quotes"""D301β User"""if any backslashes in a docstringD302β Deprecated: Useu"""for Unicode docstrings
π Docstring Content Issues π
the words themselves. the actual lore. this is where your first line has to carry π
D400β First line should end with a periodD401β First line should be in imperative moodD401β First line should be in imperative mood; try rephrasingD402β First line should not be the function's"signature"D403β First word of the first line should be properly capitalizedD404β First word of the docstring should not be ThisD405β Section name should be properly capitalizedD406β section name should end with a newline. like, the section header needs its own line break, bestie. β¨D407β missing dashed underline after section. you forgot the little-----under your section name. πD408β section underline should be in the line following the section's name. the dashes gotta be on the very next line, no skipping. πD409β section underline should match the length of its name. if your section isOPTIONS, your dashes should be that long too. periodt. πD410β missing blank line after section. need a lil breathing room after the section, okay? πΈD411β missing blank line before section. and also before the section, bestie. π¦D412β no blank lines allowed between a section header and its content. so no random empty lines right after the header. πD413β missing blank line after last section. even the final section needs a blank line after it. πD414β section has no content. a section with nothing in it? not the vibe. πD415β first line should end with a period, question mark, or exclamation point. punctuation is mandatory, fr fr. βD416β section name should end with a colon. add that:at the end of the section name. πD417β missing argument descriptions in the docstring. you gotta describe your arguments, no cap. π₯D418β function/method decorated with@overloadshouldn't contain a docstring. if it's@overload, no docstring allowed. πD419β docstring is empty. an empty docstring is giving nothing. π
Default conventions β¨
not every single error code gets checked by default, bestie. there are three conventions pydocstyle can use: pep257, numpy, and google.
- The
pep257convention (specified in PEP257) is the default one. It checks for all of the above errors exceptD203,D212,D213,D214,D215,D404,D405,D406,D407,D408,D409,D410,D411,D413,D415,D416andD417. π - The
numpyconvention was added in v2.0.0 and supports the numpydoc docstring standard. It checks all of the errors exceptD107,D203,D212,D213,D402,D413,D415,D416, andD417. π - The
googleconvention was added in v4.0.0 and supports the Google Python Style Guide. It checks for all the errors exceptD203,D204,D213,D215,D400,D401,D404,D406,D407,D408,D409andD413. π¦
You can pick a convention with --convention=<name> when you run pydocstyle from the command line, or you can set it in a configuration file. See the Usage section for more details. π
NOTE: It makes no sense to check the same docstring for bothnumpyandnumpystyle, we don't check it fornumpystyle takes precedence over
Publicity π
The D1xx group of errors is all about missing docstrings in public constructs: modules, classes, methods, etc. It's super important to know how publicity is determined and what its effects are. π
How publicity is determined π
Publicity for all constructs is determined like this: a construct is considered public if β
- Its immediate parent is public and
- Its name does not start with a single or double underscore.
- Note: names that start and end with a double underscore are public (e.g.
__init__.py). β¨
- 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's parent is usually a module, but it 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 all of its parents need to be public. The corollary: 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/baz.py. If PYTHONPATH is set to /, then baz.py is private. If PYTHONPATH is set to /_foo/, then baz.py 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's important to note that while docstrings are optional for private constructs, 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 and Sambhav Kothari.
AUTHOR β¨
Amir Rachum
COPYRIGHT π
2024, Amir Rachum, Sambhav Kothari
that's a wrap on PYDOCSTYLE(1) β version 0.0.0, dated 2024-01-14. stay iconic, bestie. πβ¨
π¦ where this page comes from
- debian trixie: pydocstyle 6.3.0-1.1 Β· MIT
- ubuntu noble: pydocstyle 6.3.0-1.1 Β· MIT
- ubuntu questing: pydocstyle 6.3.0-1.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms