mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time – a very scarce resource – which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships.
The moment you become a sponsor, you'll get immediate access to 7 additional features that you can start using right away, and which are currently exclusively available to sponsors:
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to pawamoy@pm.me with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to pawamoy@pm.me.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python. ↩
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability. ↩
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly. ↩
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to pawamoy@pm.me, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations. ↩
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable. ↩
\ No newline at end of file
+ Insiders - mkdocstrings-python
mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time – a very scarce resource – which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships.
The moment you become a sponsor, you'll get immediate access to 4 additional features that you can start using right away, and which are currently exclusively available to sponsors:
Automatic rendering of function signature overloads
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to pawamoy@pm.me with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
This section lists all funding goals that were previously completed, which means that those features were part of Insiders, but are now generally available and can be used by all users.
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to pawamoy@pm.me.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python. ↩
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability. ↩
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly. ↩
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to pawamoy@pm.me, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations. ↩
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable. ↩
\ No newline at end of file
diff --git a/search/search_index.json b/search/search_index.json
index 29093943..d996e811 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Overview","text":"mkdocstrings-python
A Python handler for mkdocstrings.
The Python handler uses Griffe to collect documentation from Python source code. The word \"griffe\" can sometimes be used instead of \"signature\" in French. Griffe is able to visit the Abstract Syntax Tree (AST) of the source code to extract useful information. It is also able to execute the code (by importing it) and introspect objects in memory when source code is not available. Finally, it can parse docstrings following different styles.
Data collection from source code: collection of the object-tree and the docstrings is done thanks to Griffe.
Support for type annotations: Griffe collects your type annotations and mkdocstrings uses them to display parameter types or return types. It is even able to automatically add cross-references to other objects from your API, from the standard library or third-party libraries! See how to load inventories to enable it.
Recursive documentation of Python objects: just use the module dotted-path as an identifier, and you get the full module docs. You don't need to inject documentation for each class, function, etc.
Support for documented attributes: attributes (variables) followed by a docstring (triple-quoted string) will be recognized by Griffe in modules, classes and even in __init__ methods.
Multiple docstring-styles support: common support for Google-style, Numpydoc-style, and Sphinx-style docstrings. See Griffe's documentation on docstrings support.
Admonition support in Google docstrings: blocks like Note: or Warning: will be transformed to their admonition equivalent. We do not support nested admonitions in docstrings!
Every object has a TOC entry: we render a heading for each object, meaning MkDocs picks them into the Table of Contents, which is nicely displayed by the Material theme. Thanks to mkdocstrings cross-reference ability, you can reference other objects within your docstrings, with the classic Markdown syntax: [this object][package.module.object] or directly with [package.module.object][]
Source code display: mkdocstrings can add a collapsible div containing the highlighted source code of the Python object.
Release Insiders features of the $500/month funding goal (bd30106 by Timoth\u00e9e Mazzucotelli). The features and projects related to mkdocstrings-python are:
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings, a Griffe extension for inheriting docstrings
griffe2md, a tool to output API docs to Markdown using Griffe
See the complete list of features and projects here: https://pawamoy.github.io/insiders/#500-plasmavac-user-guide.
Show parameter default values within the \"list\" section style too (55f08f3 by Antoine Dechaume). PR #92, Co-authored-by: Timoth\u00e9e Mazzucotelli pawamoy@pm.me
The signature of the format_signature filter has changed. If you override templates in your project to customize the output, make sure to update the following templates so that they use the new filter signature:
class.html
expression.html
function.html
signature.html
You can see how to use the filter in this commit's changes: f686f4e4.
We take this as an opportunity to go out of beta and bump the version to 1.0.0. This will allow users to rely on semantic versioning.
Return all known anchors (9bbfe14 by Timoth\u00e9e Mazzucotelli).
Update for griffe 0.4.0 (831aabb by Timoth\u00e9e Mazzucotelli).
"},{"location":"code_of_conduct/","title":"Contributor Covenant Code of Conduct","text":""},{"location":"code_of_conduct/#our-pledge","title":"Our Pledge","text":"
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at pawamoy@pm.me. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
This project uses duty to run tasks. A Makefile is also provided. The Makefile will try to run certain tasks on multiple Python versions. If for some reason you don't want to run the task on multiple Python versions, you run the task directly with pdm run duty TASK.
The Makefile detects if a virtual environment is activated, so make will work the same with the virtualenv activated or not.
If you work in VSCode, we provide an action to configure VSCode for the project.
Commit messages must follow our convention based on the Angular style or the Karma convention:
<type>[(scope)]: Subject\n\n[Body]\n
Subject and body must be valid Markdown. Subject must have proper casing (uppercase for first letter if it makes sense), but no dot at the end, and no punctuation in general.
Scope and body are optional. Type can be:
build: About packaging, building wheels, etc.
chore: About packaging or repo/files management.
ci: About Continuous Integration.
deps: Dependencies update.
docs: About documentation.
feat: New feature.
fix: Bug fix.
perf: About performance.
refactor: Changes that are not features or bug fixes.
style: A change in code style/format.
tests: About tests.
If you write a body, please add trailers at the end (for example issues and PR references, or co-authors), without relying on GitHub's flavored Markdown:
Body.\n\nIssue #10: https://github.com/namespace/project/issues/10\nRelated to PR namespace/other-project#15: https://github.com/namespace/other-project/pull/15\n
These \"trailers\" must appear at the end of the body, without any blank lines between them. The trailer title can contain any character except colons :. We expect a full URI for each trailer, not just GitHub autolinks (for example, full GitHub URLs for commits and issues, not the hash or the #issue-number).
We do not enforce a line length on commit messages summary and body, but please avoid very long summaries, and very long lines in the body, unless they are part of code blocks that must not be wrapped.
These projects were used to build mkdocstrings-python. Thank you!
python | pdm | copier-pdm
"},{"location":"credits/#exec-1--runtime-dependencies","title":"Runtime dependencies","text":"Project Summary Version (accepted) Version (last resolved) License click Composable command line interface toolkit >=7.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. >=0.40.4.6 BSD License ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License griffe Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API. >=0.370.38.1 ISC importlib-metadata Read metadata from Python packages >=4.6; python_version < \"3.10\"7.0.1 ? jinja2 A very fast and expressive template engine. >=2.11.13.1.2 BSD-3-Clause markdown Python implementation of John Gruber's Markdown. >=3.33.5.1 BSD License markupsafe Safely add untrusted strings to HTML/XML markup. >=1.12.1.3 BSD-3-Clause mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.41.5.3 BSD License mkdocs-autorefs Automatically link across pages in MkDocs. >=0.3.10.5.0 ISC mkdocstrings Automatic documentation from sources, for MkDocs. >=0.200.24.0 ISC packaging Core utilities for Python packages >=20.523.2 BSD License pathspec Utility library for gitignore style pattern matching of file paths. >=0.11.10.12.1 Mozilla Public License 2.0 (MPL 2.0) platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=2.2.04.1.0 MIT License pymdown-extensions Extension pack for Python Markdown. >=6.310.7 MIT License python-dateutil Extensions to the standard Python datetime module >=2.8.12.8.2 Dual License pyyaml YAML parser and emitter for Python 6.0.1 MIT pyyaml-env-tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT typing-extensions Backported and Experimental Type Hints for Python 3.8+ >=4.1; python_version < \"3.10\"4.9.0 Python Software Foundation License watchdog Filesystem events monitoring >=2.03.0.0 Apache License 2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.17.0 ?"},{"location":"credits/#exec-1--development-dependencies","title":"Development dependencies","text":"Project Summary Version (accepted) Version (last resolved) License ansimarkup Produce colored terminal text with an xml-like markup ~=1.41.5.0 Revised BSD License appdirs A small Python module for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=1.41.4.4 MIT babel Internationalization utilities ~=2.102.14.0 BSD-3-Clause black The uncompromising code formatter. >=23.923.12.1 MIT blacken-docs Run Black on Python code blocks in documentation files. >=1.161.16.0 MIT certifi Python package for providing Mozilla's CA Bundle. >=2017.4.172023.11.17 MPL-2.0 charset-normalizer The Real First Universal Charset Detector. Open, modern and actively maintained alternative to Chardet. <4,>=23.3.2 MIT click Composable command line interface toolkit >=8.0.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. ; platform_system == \"Windows\"0.4.6 BSD License coverage Code coverage measurement for Python [toml]>=5.2.17.4.0 Apache-2.0 csscompressor A python port of YUI CSS Compressor >=0.9.50.9.5 BSD dparse A parser for Python dependency files >=0.6.20.6.3 MIT license duty A simple task runner. >=0.101.1.0 ISC exceptiongroup Backport of PEP 654 (exception groups) >=1.0.0rc8; python_version < \"3.11\"1.2.0 ? execnet execnet: rapid multi-Python deployment >=1.12.0.2 MIT License failprint Run a command, print its output only if it fails. !=1.0.0,>=0.111.0.2 ISC ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License git-changelog Automatic Changelog generator using Jinja2 templates. >=2.32.4.0 ISC gitdb Git Object Database <5,>=4.0.14.0.11 BSD License gitpython GitPython is a Python library used to interact with Git repositories 3.1.40 BSD htmlmin2 An HTML Minifier >=0.1.130.1.13 BSD idna Internationalized Domain Names in Applications (IDNA) <4,>=2.53.6 BSD License importlib-metadata Read metadata from Python packages >=4.3; python_version < \"3.10\"7.0.1 ? iniconfig brain-dead simple config-ini parsing 2.0.0 MIT License jinja2 A very fast and expressive template engine. <4,>=2.113.1.2 BSD-3-Clause jsmin JavaScript minifier. >=3.0.13.0.1 MIT License markdown Python implementation of John Gruber's Markdown. <4.0.0,>=3.3.33.5.1 BSD License markdown-callouts Markdown extension: a classier syntax for admonitions >=0.30.3.0 MIT markdown-exec Utilities to execute code blocks in Markdown files. >=1.71.8.0 ISC markupsafe Safely add untrusted strings to HTML/XML markup. >=2.02.1.3 BSD-3-Clause mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.51.5.3 BSD License mkdocs-coverage MkDocs plugin to integrate your coverage HTML report into your site. >=1.01.0.0 ISC mkdocs-gen-files MkDocs plugin to programmatically generate documentation pages during the build >=0.50.5.0 MIT License mkdocs-git-committers-plugin-2 An MkDocs plugin to create a list of contributors on the page. The git-committers plugin will seed the template context with a list of GitHub or GitLab committers and other useful GIT info such as last modified date >=1.22.2.3 MIT mkdocs-literate-nav MkDocs plugin to specify the navigation in Markdown instead of YAML >=0.60.6.1 MIT License mkdocs-material Documentation that simply works >=9.49.5.3 MIT License mkdocs-material-extensions Extension pack for Python Markdown and MkDocs Material. ~=1.31.3.1 MIT License mkdocs-minify-plugin An MkDocs plugin to minify HTML, JS or CSS files prior to being written to disk >=0.70.7.2 MIT mypy Optional static typing for Python >=1.51.8.0 MIT mypy-extensions Type system extensions for programs checked with the mypy type checker. >=0.4.31.0.0 MIT License packaging Core utilities for Python packages >=22.023.2 BSD License paginate Divides large result sets into pages for easier browsing ~=0.50.5.6 MIT pathspec Utility library for gitignore style pattern matching of file paths. >=0.9.00.12.1 Mozilla Public License 2.0 (MPL 2.0) platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=24.1.0 MIT License pluggy plugin and hook calling mechanisms for python <2.0,>=0.121.3.0 MIT ptyprocess Run a subprocess in a pseudo terminal ~=0.6; sys_platform != \"win32\"0.7.0 ISC License (ISCL) pygments Pygments is a syntax highlighting package written in Python. ~=2.162.17.2 BSD-2-Clause pymdown-extensions Extension pack for Python Markdown. >=910.7 MIT License pytest pytest: simple powerful testing with Python >=7.47.4.4 MIT pytest-cov Pytest plugin for measuring coverage. >=4.14.1.0 MIT pytest-randomly Pytest plugin to randomly order tests and control random.seed. >=3.153.15.0 MIT pytest-xdist pytest xdist plugin for distributed testing, most importantly across multiple CPUs >=3.33.5.0 MIT python-dateutil Extensions to the standard Python datetime module >=2.8.12.8.2 Dual License pytz World timezone definitions, modern and historical >=2015.7; python_version < \"3.9\"2023.3.post1 ? pyyaml YAML parser and emitter for Python >=5.16.0.1 MIT pyyaml-env-tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License regex Alternative regular expression module, to replace re. >=2022.42023.12.25 Apache Software License requests Python HTTP for Humans. 2.31.0 Apache 2.0 ruamel-yaml ruamel.yaml is a YAML parser/emitter that supports roundtrip preservation of comments, seq/map flow style, and map key order >=0.17.210.18.5 MIT license ruamel-yaml-clib C version of reader, parser and emitter for ruamel.yaml derived from libyaml >=0.2.7; platform_python_implementation == \"CPython\" and python_version < \"3.13\"0.2.8 MIT ruff An extremely fast Python linter and code formatter, written in Rust. >=0.00.1.11 MIT safety Checks installed dependencies for known vulnerabilities and licenses. >=2.32.3.4 MIT license semver Python helper for Semantic Versioning (https://semver.org) >=2.133.0.2 BSD setuptools Easily download, build, install, upgrade, and uninstall Python packages >=19.369.0.3 MIT License six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT smmap A pure Python implementation of a sliding window memory map manager <6,>=3.0.15.0.1 BSD tomli A lil' TOML parser >=2.0; python_version < '3.11'2.0.1 ? types-markdown Typing stubs for Markdown >=3.53.5.0.20240106 Apache-2.0 license types-pyyaml Typing stubs for PyYAML >=6.06.0.12.12 Apache-2.0 license typing-extensions Backported and Experimental Type Hints for Python 3.8+ >=4.0.1; python_version < \"3.11\"4.9.0 Python Software Foundation License urllib3 HTTP library with thread-safe connection pooling, file post, and more. <3,>=1.21.12.1.0 MIT License watchdog Filesystem events monitoring >=2.03.0.0 Apache License 2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.17.0 ?
ISC License\n\nCopyright (c) 2021, Timoth\u00e9e Mazzucotelli\n\nPermission to use, copy, modify, and/or distribute this software for any\npurpose with or without fee is hereby granted, provided that the above\ncopyright notice and this permission notice appear in all copies.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES\nWITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF\nMERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR\nANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES\nWHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN\nACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF\nOR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.\n
mkdocstrings-python follows the sponsorware release strategy, which means that new features are first exclusively released to sponsors as part of Insiders. Read on to learn what sponsorships achieve, how to become a sponsor to get access to Insiders, and what's in it for you!
"},{"location":"insiders/#what-is-insiders","title":"What is Insiders?","text":"
mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1 all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time \u2013 a very scarce resource \u2013 which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships.
"},{"location":"insiders/#whats-in-it-for-me","title":"What's in it for me?","text":"
The moment you become a sponsor, you'll get immediate access to 7 additional features that you can start using right away, and which are currently exclusively available to sponsors:
griffe-inherited-docstrings \u2014 [Project] Griffe extension for inheriting docstrings
Automatic rendering of function signature overloads
Auto-summary of object members
griffe-typing-deprecated \u2014 [Project] Griffe extension for @typing.deprecated (PEP 702)
griffe-pydantic \u2014 [Project] Griffe extension for Pydantic
Symbol types in headings and table of contents
Cross-references for type annotations in signatures
"},{"location":"insiders/#how-to-become-a-sponsor","title":"How to become a sponsor","text":"
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to pawamoy@pm.me with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
You can cancel your sponsorship anytime.5
\u00a0 Join our awesome sponsors
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
"},{"location":"insiders/#500-plasmavac-user-guide","title":"$ 500 \u2014 PlasmaVac User Guide","text":"
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings \u2014 [Project] Griffe extension for inheriting docstrings
"},{"location":"insiders/#1000-gravifridge-user-manual","title":"$ 1,000 \u2014 GraviFridge User Manual","text":"
Auto-summary of object members
Automatic rendering of function signature overloads
griffe-pydantic \u2014 [Project] Griffe extension for Pydantic
griffe-typing-deprecated \u2014 [Project] Griffe extension for @typing.deprecated (PEP 702)
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to pawamoy@pm.me.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python.\u00a0\u21a9
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability.\u00a0\u21a9
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly.\u00a0\u21a9
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to pawamoy@pm.me, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations.\u00a0\u21a9
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable.\u00a0\u21a9
"},{"location":"insiders/changelog/","title":"Changelog","text":""},{"location":"insiders/changelog/#mkdocstrings-python-insiders","title":"mkdocstrings-python Insiders","text":""},{"location":"insiders/changelog/#1.5.1","title":"1.5.1 September 12, 2023","text":"
Prevent empty auto-summarized Methods section.
"},{"location":"insiders/changelog/#1.5.0","title":"1.5.0 September 05, 2023","text":"
Render function signature overloads.
"},{"location":"insiders/changelog/#1.4.0","title":"1.4.0 August 27, 2023","text":"
Render cross-references in attribute signatures.
"},{"location":"insiders/changelog/#1.3.0","title":"1.3.0 August 24, 2023","text":"
Add \"method\" symbol type.
"},{"location":"insiders/changelog/#1.2.0","title":"1.2.0 August 20, 2023","text":"
Add member auto-summaries.
"},{"location":"insiders/changelog/#1.1.4","title":"1.1.4 July 17, 2023","text":"
Fix heading level increment for class members.
"},{"location":"insiders/changelog/#1.1.3","title":"1.1.3 July 17, 2023","text":"
Fix heading level (avoid with clause preventing to decrease it).
"},{"location":"insiders/changelog/#1.1.2","title":"1.1.2 July 15, 2023","text":"
Use non-breaking spaces after symbol types.
"},{"location":"insiders/changelog/#1.1.1","title":"1.1.1 June 27, 2023","text":"
Correctly escape expressions in signatures and other rendered types.
"},{"location":"insiders/changelog/#1.1.0","title":"1.1.0 June 4, 2023","text":"
Add Symbol types in headings and table of contents.
"},{"location":"insiders/changelog/#1.0.0","title":"1.0.0 May 10, 2023","text":"
Add cross-references for type annotations in signatures. Make sure to update your local templates as the signature of the format_signature filter has changed. The templates that must be updated: class.html, expression.html, function.html and signature.html.
"},{"location":"insiders/installation/","title":"Getting started with Insiders","text":"
mkdocstrings-python Insiders is a compatible drop-in replacement for mkdocstrings-python, and can be installed similarly using pip or git. Note that in order to access the Insiders repository, you need to become an eligible sponsor of @pawamoy on GitHub.
PyPI Insiders is a tool that helps you keep up-to-date versions of Insiders projects in the PyPI index of your choice (self-hosted, Google registry, Artifactory, etc.).
The GH_TOKEN environment variable is a GitHub token. It can be obtained by creating a personal access token for your GitHub account. It will give you access to the Insiders repository, programmatically, from the command line or GitHub Actions workflows:
Go to https://github.com/settings/tokens
Click on Generate a new token
Enter a name and select the repo scope
Generate the token and store it in a safe place
Note that the personal access token must be kept secret at all times, as it allows the owner to access your private repositories.
Self-hosting the Insiders package makes it possible to depend on mkdocstrings-python normally, while transparently downloading and installing the Insiders version locally. It means that you can specify your dependencies normally, and your contributors without access to Insiders will get the public version, while you get the Insiders version on your machine.
Limitation
With this method, there is no way to force the installation of an Insiders version rather than a public version. If there is a public version that is more recent than your self-hosted Insiders version, the public version will take precedence. Remember to regularly update your self-hosted versions by uploading latest distributions.
You can build the distributions for Insiders yourself, by cloning the repository and using build to build the distributions, or you can download them from our GitHub Releases. You can upload these distributions to a private PyPI-like registry (Artifactory, Google Cloud, pypiserver, etc.) with Twine:
# download distributions in ~/dists, then upload with:\ntwine upload --repository-url https://your-private-index.com ~/dists/*\n
You might also need to provide a username and password/token to authenticate against the registry. Please check Twine's documentation.
You can then configure pip (or other tools) to look for packages into your package index. For example, with pip:
pip config set global.extra-index-url https://your-private-index.com/simple\n
Note that the URL might differ depending on whether your are uploading a package (with Twine) or installing a package (with pip), and depending on the registry you are using (Artifactory, Google Cloud, etc.). Please check the documentation of your registry to learn how to configure your environment.
We kindly ask that you do not upload the distributions to public registries, as it is against our Terms of use.
Full example with pypiserver
In this example we use pypiserver to serve a local PyPI index.
pip install --user pypiserver\n# or pipx install pypiserver\n\n# create a packages directory\nmkdir -p ~/.local/pypiserver/packages\n\n# run the pypi server without authentication\npypi-server run -p 8080 -a . -P . ~/.local/pypiserver/packages &\n
We can configure the credentials to access the server in ~/.pypirc:
We then clone the Insiders repository, build distributions and upload them to our local server:
# clone the repository\ngit clone git@github.com:pawamoy-insiders/mkdocstrings-python\ncd python\n\n# install build\npip install --user build\n# or pipx install build\n\n# checkout latest tag\ngit checkout $(git describe --tags --abbrev=0)\n\n# build the distributions\npyproject-build\n\n# upload them to our local server\ntwine upload -r local dist/* --skip-existing\n
Finally, we configure pip, and for example PDM, to use our local index to find packages:
pip config set global.extra-index-url http://localhost:8080/simple\npdm config pypi.extra.url http://localhost:8080/simple\n
Now when running pip install mkdocstrings-python, or resolving dependencies with PDM, both tools will look into our local index and find the Insiders version. Remember to update your local index regularly!
When upgrading Insiders, you should always check the version of mkdocstrings-python which makes up the first part of the version qualifier. For example, a version like 8.x.x.4.x.x means that Insiders 4.x.x is currently based on 8.x.x.
If the major version increased, it's a good idea to consult the changelog and go through the steps to ensure your configuration is up to date and all necessary changes have been made.
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See parsers under griffe.docstrings.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
Filters to apply, based on members' names. Each element is a tuple: a pattern, and a boolean indicating whether to reject the object if the pattern matches.
An optional, explicit list of members to keep. When given and empty, return an empty list. When given and not empty, ignore filters and docstrings presence/absence.
You can install this handler as a mkdocstrings extra:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings[python]>=0.18\",\n]\n
You can also explicitly depend on the handler:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings-python\",\n]\n
The Python handler is the default mkdocstrings handler. You can change the default handler, or explicitely set the Python handler as default by defining the default_handler configuration option of mkdocstrings in mkdocs.yml:
With the Python handler installed and configured as default handler, you can inject documentation for a module, class, function, or any other Python object with mkdocstrings' autodoc syntax, in your Markdown pages:
::: path.to.object\n
If another handler was defined as default handler, you can explicitely ask for the Python handler to be used when injecting documentation with the handler option:
This option is used to import Sphinx-compatible objects inventories from other documentation sites. For example, you can import the standard library objects inventory like this:
When importing an inventory, you enable automatic cross-references to other documentation sites like the standard library docs or any third-party package docs. Typically, you want to import the inventories of your project's dependencies, at least those that are used in the public API.
See mkdocstrings' documentation on inventories for more details.
Additionally, the Python handler accepts a domains option in the import items, which allows to select the inventory domains to select. By default the Python handler only selects the py domain (for Python objects). You might find useful to also enable the std domain:
This option is used to provide filesystem paths in which to search for Python modules. Non-absolute paths are computed as relative to MkDocs configuration file. Example:
mkdocs.yml
plugins:\n- mkdocstrings:\n handlers:\n python:\n paths: [src] # search packages in the src folder\n
This option allows resolving aliases (imports) to any external module. Modules are considered external when they are not part of the package your are injecting documentation for. Enabling this option will tell the handler to resolve aliases recursively when they are made public through the __all__ variable.
Use with caution
This can load a lot of modules through Griffe, slowing down your build or triggering errors that Griffe does not yet handle. We recommend using the preload_modules option instead, which acts as an include-list rather than as include-all.
These options affect how the documentation is collected from sources and rendered. See the following tables summarizing the options, and get more details for each option in the following pages:
General options: various options that do not fit in the other categories
Headings options: options related to headings and the table of contents (or sidebar, depending on the theme used)
Members options: options related to filtering or ordering members in the generated documentation
Docstrings options: options related to docstrings (parsing and rendering)
Signature options: options related to signatures and type annotations
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See parsers under griffe.docstrings.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
There are multiple ways to tell the handler where to find your packages/modules.
The recommended method is to use the paths option, as it's the only one that works with the -f option of MkDocs, allowing to build the documentation from any location on the file system. Indeed, the paths provided with the paths option are computed as relative to the configuration file (mkdocs.yml), so that the current working directory has no impact on the build process: you can build the docs from any location on your filesystem.
"},{"location":"usage/#using-the-paths-option","title":"Using the paths option","text":"
Except for case 1, which is supported by default, we strongly recommend setting the path to your packages using this option, even if it works without it (for example because your project manager automatically adds src to PYTHONPATH), to make sure anyone can build your docs from any location on their filesystem.
"},{"location":"usage/#using-the-pythonpath-environment-variable","title":"Using the PYTHONPATH environment variable","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
You can take advantage of the usual Python loading mechanisms. In Bash and other shells, you can run your command like this (note the prepended PYTHONPATH=...):
"},{"location":"usage/#installing-your-package-in-the-current-python-environment","title":"Installing your package in the current Python environment","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
Install your package in the current environment, and run MkDocs:
You can customize the colors of the symbol types (see show_symbol_type_heading and show_symbol_type_toc) by overriding the values of our CSS variables, for example:
The [data-md-color-scheme=\"*\"] selectors work with the Material for MkDocs theme. If you are using another theme, adapt the selectors to this theme if it supports light and dark themes, otherwise just override the variables at root level:
See them in the repository. See the general mkdocstrings documentation to learn how to override them: https://mkdocstrings.github.io/theming/#templates.
Each one of these templates extends a base version in theme/_base. Example:
theme/class.html
{% extends \"_base/class.html\" %}\n
Some of these templates define Jinja blocks. allowing to customize only parts of a template without having to fully copy-paste it into your project:
Only the templates for the Material for MkDocs provide Jinja blocks. The following tables show the block names, description, and the Jinja context available in their scope.
"},{"location":"usage/extensions/","title":"Extensions","text":""},{"location":"usage/extensions/#work-in-progress","title":"Work in Progress!","text":"
The Python handler supports extensions through mkdocstrings' handler extensions.
Specifically, additional templates can be added to the handler, and Griffe extensions can instruct the handler to use a particular template for a particular object by setting a value in the Griffe object's extra dictionary:
griffe_extension.py
obj = ... # get a reference to a Griffe object\nif \"mkdocstrings\" not in obj.extra:\n obj.extra[\"mkdocstrings\"] = {}\nobj.extra[\"mkdocstrings\"][\"template\"] = \"template_name.html\"\n
Every style gets rendered the same way. Here are some docstring examples.
GoogleNumpySphinx
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters:\n name: The name of the person to greet.\n\n Returns:\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters\n ----------\n name\n The name of the person to greet.\n\n Returns\n -------\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n :param name: The name of the person to greet.\n :return: A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
A section is a block of text that has a special meaning in a docstring. There are sections for documenting attributes of an object, parameters of a function, exceptions raised by a function, the return value of a function, etc.
Sections are parsed as structured data and can therefore be rendered in different ways. Possible values:
\"table\": a simple table, usually with type, name and description columns
\"list\": a simple list, akin to what you get with the ReadTheDocs Sphinx theme
\"spacy\": a poor implementation of the amazing tables in Spacy's documentation
Tables work well when you have lots of items with short names, type annotations, descriptions, etc.. With longer strings, the columns risk getting squished horizontally. In that case, the Spacy tables can help.
Parameters:
Type Name Description Default intthreshold Threshold for something. required boolflag Enable something. False
Other Parameters:
Type Name Description Default list[int | float]gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. required VacuumType | Literal[\"regular\"]vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. VacuumType.PLASMA
Lists work well whatever the length of names, type annotations, descriptions, etc.
Parameters:
threshold (int) \u2014 Threshold for something.
flag (bool) \u2014 Enable something.
Other Parameters:
gravity_forces (list[int | float]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
vacuum_type (VacuumType | Literal[\"regular\"]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Spacy tables work better than regular tables with longer names, type annotations, descriptions, etc., by reserving more horizontal space on the second column.
Parameters:
Name Description threshold Threshold for something.TYPE: int DEFAULT: required flag Enable something.TYPE: bool DEFAULT: False
Other Parameters:
Name Description gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE: list[int | float] DEFAULT: required vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE:VacuumType | Literal[\"regular\"] DEFAULT: VacuumType.PLASMA"},{"location":"usage/configuration/docstrings/#merge_init_into_class","title":"merge_init_into_classThing(value=0)Thing","text":"
Type boolFalse
Whether to merge the __init__ method into the class' signature and docstring.
By default, only the class name is rendered in headings. When merging, the __init__ method parameters are added after the class name, like a signature, and the __init__ method docstring is appended to the class' docstring. This option is well used in combination with the ignore_init_summary docstring option, to discard the first line of the __init__ docstring which is not often useful.
class Thing:\n \"\"\"A class for things.\"\"\"\n\n def __init__(self, value: int = 0):\n \"\"\"Initialize a thing.\n\n Parameters:\n value: The thing's value.\n \"\"\"\n self.value = value\n
Preview
Merged, summary discardedUnmerged, summary kept
Class docstring.
Parameters:
Type Name Description Default intvalue The thing's value. 0
Class docstring.
__init__(value=0)
Initialize a thing.
Parameters:
Type Name Description Default intvalue The thing's value. 0"},{"location":"usage/configuration/docstrings/#show_if_no_docstring","title":"show_if_no_docstringfunction_without_docstringfunction_with_docstringClassWithoutDocstringfunction_with_docstringClassWithoutDocstring","text":"
Type boolFalse
Show the object heading even if it has no docstring or children with docstrings.
Without an explicit list of members, members are selected based on filters, and then filtered again to keep only those with docstrings. Checking if a member has a docstring is done recursively: if at least one of its direct or indirect members (lower in the tree) has a docstring, the member is rendered. If the member does not have a docstring, and none of its members have a docstring, it is excluded.
With this option you can tell the Python handler to skip the docstring check.
class Class:\n \"\"\"Summary.\n\n Long description.\n\n Warning: Deprecated\n Stop using this class.\n\n Attributes:\n attr: Some attribute.\n \"\"\"\n\n attr: int = 1\n
Preview
With description blocksWithout description blocks
Summary.
Long description.
Deprecated
Stop using this class.
Attributes:
Type Name Description intattr Some attribute.
Attributes:
Type Name Description intattr Some attribute."},{"location":"usage/configuration/docstrings/#show_docstring_examples","title":"show_docstring_examplesprint_helloprint_hello","text":"
Type boolTrue
Whether to render the \"Examples\" section of docstrings.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Receives:\n skip: Number of elements to skip.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
def warn():\n \"\"\"Warn user.\n\n Warns:\n UserWarning: When this is inappropriate.\n \"\"\"\n warnings.warn(UserWarning(\"This is inappropriate\"))\n
Preview
With warningsWithout warnings
Warn user.
Warns:
Type Description UserWarning When this is inappropriate.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Yields:\n Elements of the iterable.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
Whether to allow inspecting modules (importing them) when it is not possible to visit them (parse their source code).
When loading data for a given package, Griffe discovers every Python module, compiled or not, and inspects or visits them accordingly.
If you have compiled modules but also provide stubs for them, you might want to disable the inspection of these modules, because inspection picks up many more members, and sometimes the collected data is inaccurate (depending on the tool that was used to compile the module) or too low-level/technical for API documentation.
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module. The package from which the imported object originates must be accessible to the handler (see Finding modules).
When injecting documentation for an object, the object itself and its members are rendered. For each layer of objects, we increase the heading level by 1.
The initial heading level will be used for the first layer. If you set it to 3, then headings will start with <h3>.
If the heading for the root object is not shown, then the initial heading level is used for its members.
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::).
It is pretty common to inject documentation for one module per page, especially when following our automatic reference pages recipe. Since each page already has a title, usually being the module's name, we can spare one heading level by not showing the heading for the module itself (heading levels are limited to 6 by the HTML specification).
Sparing that extra level can be helpful when your objects tree is deeply nested (e.g. method in a class in a class in a module). If your objects tree is not deeply nested, and you are injecting documentation for many different objects on a single page, it might be preferable to render the heading of each object.
If the root heading is not shown, at least add a ToC entry for it.
If you inject documentation for an object in the middle of a page, after long paragraphs, and without showing the root heading, then you will not be able to link to this particular object as it won't have a permalink and will be \"lost\" in the middle of text. In that case, it is useful to add a hidden anchor to the document, which will also appear in the table of contents.
In other cases, you might want to disable the entry to avoid polluting the ToC. It is not possible to show the root heading and hide the ToC entry.
Show the full Python path for the root object heading.
The path of a Python object is the dot-separated list of names under which it is accessible, for example package.module.Class.method.
With this option you can choose to show the full path of the object you inject documentation for, or just its name. This option impacts only the object you specify, not its members. For members, see the two other options show_root_members_full_path and show_object_full_path.
Same as for show_root_members_full_path, but for every member, recursively. This option takes precedence over show_root_members_full_path:
show_root_members_full_pathshow_object_full_path Direct root members path False False Name only False True Full True False Full True True Full in mkdocs.yml (global configuration)
When grouped by categories, show a heading for each category. These category headings will appear in the table of contents, allowing you to link to them using their permalinks.
Not recommended with deeply nested object
When injecting documentation for deeply nested objects, you'll quickly run out of heading levels, and the objects at the bottom of the tree risk all getting documented using H6 headings, which might decrease the readability of your API docs.
Only members declared in this list will be rendered. A member without a docstring will still be rendered, even if show_if_no_docstring is set to false.
The members will be rendered in the specified order, regardless of the value of members_order.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every member.
Any given value, except for an explicit None (null in YAML) will tell the handler to ignore filters for the object's members. Filters will still be applied to the next layers of members (grand-children).
An explicit list of inherited members (for classes) to render.
Inherited members are always fetched from classes that are in the same package as the currently rendered class. To fetch members inherited from base classes, themselves coming from external packages, use the preload_modules option. For example, if your class inherits from Pydantic's BaseModel, and you want to render BaseModel's methods in your class, use preload_modules: [pydantic]. The pydantic package must be available in the current environment.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any inherited member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every inherited member.
When all inherited members are selected with inherited_members: true, it is possible to specify both members and inherited members in the members list:
In this case, only declared members will be subject to further filtering with filters and docstrings.
inherited_members: true # (1)\n# members: null\n
In this case, both declared and inherited members will be subject to further filtering with filters and docstrings.
You can render all declared members and all or specific inherited members, avoiding further filtering with filters and docstrings by setting members: true:
A list of filters applied to filter objects based on their name.
Filters are regular expressions. These regular expressions are evaluated by Python and so must match the syntax supported by the re module. A filter starting with ! (negative filter) will exclude matching objects instead of including them.
The default value ([\"!^_[^_]\"]) means: render every object, except those starting with one underscore, unless they start with two underscores. It means that an object whose name is hello, __hello, or __hello__ will be rendered, but not one whose name is _hello.
Each filter takes precedence over the previous one. This allows for fine-grain selection of objects by adding more specific filters. For example, you can start by unselecting objects that start with _, and add a second filter that re-select objects that start with __. The default filters can therefore be rewritten like this:
filters:\n- \"!^_\"\n- \"^__\"\n
If there are no negative filters, the handler considers that everything is unselected first, and then selects things based on your positive filters. If there is at least one negative filter, the handler considers that everything is selected first, and then re-selects/unselects things based on your other filters. In short, filters: [\"a\"] means \"keep nothing except names containing a\", while filters: [\"!a\"] means \"keep everything except names containing a\".
An empty list of filters tells the Python handler to render every object. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy).
Group the object members by categories: attributes, classes, functions, and modules.
Members within a same category will be ordered according to the members_order option. You can use the show_category_heading option to also render a heading for each category.
When rendering a module, show its submodules recursively.
This is false by default, because most of the time we render only one module per page, and when rendering a package (a tree of modules and their members) on a single page, we quickly run out of heading levels.
Whether to render summaries of modules, classes, functions (methods) and attributes.
This option accepts a boolean (yes, true, no, false in YAML) or a dictionary with one or more of the following keys: attributes, functions, classes, modules, with booleans as values. Class methods summary is (de)activated with the functions key. By default, summary is false, and by extension all values are false.
Summaries will be rendered as the corresponding docstring sections. For example, the summary for attributes will be rendered as an Attributes docstring section. The section will be rendered in accordance with the docstring_section_style option. If the objects appearing in the summary are also rendered on the page (or somewhere else on the site), their name will automatically link to their rendered documentation.
brief (recommended): render only the last component of each type path, not their full paths. For example, it will render Sequence[Path] and not typing.Sequence[pathlib.Path]. Brief annotations will cross-reference the right object anyway, and show the full path in a tooltip when hovering them.
source: render annotations as written in the source. For example if you imported typing as t, it will render typing.Sequence as t.Sequence. Each part will cross-reference the relevant object: t will link to the typing module and Sequence will link to the Sequence type.
full: render annotations with their full path (the opposite of brief). For example if you import Sequence and Pattern from typing and annoate something using Sequence[Pattern], it will render as typing.Sequence[typing.Pattern], with each part cross-referencing the corresponding object.
import markdown\nimport markupsafe\n\n\ndef convert(text: str, md: markdown.Markdown) -> markupsafe.Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return markupsafe.Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
import markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: markdown.Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
from markdown import Markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description markupsafe.Markuptext Converted markup."},{"location":"usage/configuration/signatures/#line_length","title":"line_lengthlong_function_namelong_function_name","text":"
Type int60
Maximum line length when formatting code/signatures.
When separating signatures from headings with the separate_signature option, the Python handler will try to format the signatures using Black and the specified line length.
If Black is not installed, the handler issues an INFO log once.
Whether to render cross-references for type annotations in signatures.
When signatures are separated from headings with the separate_signature option and type annotations are shown with the show_signature_annotations option, this option will render a cross-reference (link) for each type annotation in the signature.
"},{"location":"usage/docstrings/google/","title":"Google style","text":""},{"location":"usage/docstrings/google/#work-in-progress","title":"Work in Progress!","text":""},{"location":"usage/docstrings/google/#google-style-admonitions","title":"Google-style admonitions","text":"
With Google-style docstrings, any section that is not recognized will be transformed into its admonition equivalent. For example:
DocstringResult
\"\"\"\nNote:\n It looks like a section, but it will be rendered as an admonition.\n\nTip: You can even choose a title.\n This admonition has a custom title!\n\"\"\"\n
Note
It looks like a section, but it will be rendered as an admonition.
You can even choose a title.
This admonition has a custom title!
See Napoleon's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/numpy/","title":"Numpydoc style","text":""},{"location":"usage/docstrings/numpy/#work-in-progress","title":"Work in Progress!","text":"
Note
As Numpy-style is partially supported by the underlying parser, you may experience problems in the building process if your docstring has a Methods section in the class docstring (see #366).
See Numpydoc's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/sphinx/","title":"Sphinx style","text":""},{"location":"usage/docstrings/sphinx/#work-in-progress","title":"Work in Progress!","text":"
See Sphinx's documentation. See the supported docstring sections on Griffe's documentation.
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Overview","text":"mkdocstrings-python
A Python handler for mkdocstrings.
The Python handler uses Griffe to collect documentation from Python source code. The word \"griffe\" can sometimes be used instead of \"signature\" in French. Griffe is able to visit the Abstract Syntax Tree (AST) of the source code to extract useful information. It is also able to execute the code (by importing it) and introspect objects in memory when source code is not available. Finally, it can parse docstrings following different styles.
Data collection from source code: collection of the object-tree and the docstrings is done thanks to Griffe.
Support for type annotations: Griffe collects your type annotations and mkdocstrings uses them to display parameter types or return types. It is even able to automatically add cross-references to other objects from your API, from the standard library or third-party libraries! See how to load inventories to enable it.
Recursive documentation of Python objects: just use the module dotted-path as an identifier, and you get the full module docs. You don't need to inject documentation for each class, function, etc.
Support for documented attributes: attributes (variables) followed by a docstring (triple-quoted string) will be recognized by Griffe in modules, classes and even in __init__ methods.
Multiple docstring-styles support: common support for Google-style, Numpydoc-style, and Sphinx-style docstrings. See Griffe's documentation on docstrings support.
Admonition support in Google docstrings: blocks like Note: or Warning: will be transformed to their admonition equivalent. We do not support nested admonitions in docstrings!
Every object has a TOC entry: we render a heading for each object, meaning MkDocs picks them into the Table of Contents, which is nicely displayed by the Material theme. Thanks to mkdocstrings cross-reference ability, you can reference other objects within your docstrings, with the classic Markdown syntax: [this object][package.module.object] or directly with [package.module.object][]
Source code display: mkdocstrings can add a collapsible div containing the highlighted source code of the Python object.
Release Insiders features of the $500/month funding goal (bd30106 by Timoth\u00e9e Mazzucotelli). The features and projects related to mkdocstrings-python are:
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings, a Griffe extension for inheriting docstrings
griffe2md, a tool to output API docs to Markdown using Griffe
See the complete list of features and projects here: https://pawamoy.github.io/insiders/#500-plasmavac-user-guide.
Show parameter default values within the \"list\" section style too (55f08f3 by Antoine Dechaume). PR #92, Co-authored-by: Timoth\u00e9e Mazzucotelli pawamoy@pm.me
The signature of the format_signature filter has changed. If you override templates in your project to customize the output, make sure to update the following templates so that they use the new filter signature:
class.html
expression.html
function.html
signature.html
You can see how to use the filter in this commit's changes: f686f4e4.
We take this as an opportunity to go out of beta and bump the version to 1.0.0. This will allow users to rely on semantic versioning.
Return all known anchors (9bbfe14 by Timoth\u00e9e Mazzucotelli).
Update for griffe 0.4.0 (831aabb by Timoth\u00e9e Mazzucotelli).
"},{"location":"code_of_conduct/","title":"Contributor Covenant Code of Conduct","text":""},{"location":"code_of_conduct/#our-pledge","title":"Our Pledge","text":"
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at pawamoy@pm.me. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
This project uses duty to run tasks. A Makefile is also provided. The Makefile will try to run certain tasks on multiple Python versions. If for some reason you don't want to run the task on multiple Python versions, you run the task directly with pdm run duty TASK.
The Makefile detects if a virtual environment is activated, so make will work the same with the virtualenv activated or not.
If you work in VSCode, we provide an action to configure VSCode for the project.
Commit messages must follow our convention based on the Angular style or the Karma convention:
<type>[(scope)]: Subject\n\n[Body]\n
Subject and body must be valid Markdown. Subject must have proper casing (uppercase for first letter if it makes sense), but no dot at the end, and no punctuation in general.
Scope and body are optional. Type can be:
build: About packaging, building wheels, etc.
chore: About packaging or repo/files management.
ci: About Continuous Integration.
deps: Dependencies update.
docs: About documentation.
feat: New feature.
fix: Bug fix.
perf: About performance.
refactor: Changes that are not features or bug fixes.
style: A change in code style/format.
tests: About tests.
If you write a body, please add trailers at the end (for example issues and PR references, or co-authors), without relying on GitHub's flavored Markdown:
Body.\n\nIssue #10: https://github.com/namespace/project/issues/10\nRelated to PR namespace/other-project#15: https://github.com/namespace/other-project/pull/15\n
These \"trailers\" must appear at the end of the body, without any blank lines between them. The trailer title can contain any character except colons :. We expect a full URI for each trailer, not just GitHub autolinks (for example, full GitHub URLs for commits and issues, not the hash or the #issue-number).
We do not enforce a line length on commit messages summary and body, but please avoid very long summaries, and very long lines in the body, unless they are part of code blocks that must not be wrapped.
These projects were used to build mkdocstrings-python. Thank you!
python | pdm | copier-pdm
"},{"location":"credits/#exec-1--runtime-dependencies","title":"Runtime dependencies","text":"Project Summary Version (accepted) Version (last resolved) License click Composable command line interface toolkit >=7.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. >=0.40.4.6 BSD License ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License griffe Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API. >=0.370.38.1 ISC importlib-metadata Read metadata from Python packages >=4.6; python_version < \"3.10\"7.0.1 ? jinja2 A very fast and expressive template engine. >=2.11.13.1.2 BSD-3-Clause markdown Python implementation of John Gruber's Markdown. >=3.33.5.1 BSD License markupsafe Safely add untrusted strings to HTML/XML markup. >=1.12.1.3 BSD-3-Clause mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.41.5.3 BSD License mkdocs-autorefs Automatically link across pages in MkDocs. >=0.3.10.5.0 ISC mkdocstrings Automatic documentation from sources, for MkDocs. >=0.200.24.0 ISC packaging Core utilities for Python packages >=20.523.2 BSD License pathspec Utility library for gitignore style pattern matching of file paths. >=0.11.10.12.1 Mozilla Public License 2.0 (MPL 2.0) platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=2.2.04.1.0 MIT License pymdown-extensions Extension pack for Python Markdown. >=6.310.7 MIT License python-dateutil Extensions to the standard Python datetime module >=2.8.12.8.2 Dual License pyyaml YAML parser and emitter for Python 6.0.1 MIT pyyaml-env-tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT typing-extensions Backported and Experimental Type Hints for Python 3.8+ >=4.1; python_version < \"3.10\"4.9.0 Python Software Foundation License watchdog Filesystem events monitoring >=2.03.0.0 Apache License 2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.17.0 ?"},{"location":"credits/#exec-1--development-dependencies","title":"Development dependencies","text":"Project Summary Version (accepted) Version (last resolved) License ansimarkup Produce colored terminal text with an xml-like markup ~=1.41.5.0 Revised BSD License appdirs A small Python module for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=1.41.4.4 MIT babel Internationalization utilities ~=2.102.14.0 BSD-3-Clause black The uncompromising code formatter. >=23.923.12.1 MIT blacken-docs Run Black on Python code blocks in documentation files. >=1.161.16.0 MIT certifi Python package for providing Mozilla's CA Bundle. >=2017.4.172023.11.17 MPL-2.0 charset-normalizer The Real First Universal Charset Detector. Open, modern and actively maintained alternative to Chardet. <4,>=23.3.2 MIT click Composable command line interface toolkit >=8.0.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. ; platform_system == \"Windows\"0.4.6 BSD License coverage Code coverage measurement for Python [toml]>=5.2.17.4.0 Apache-2.0 csscompressor A python port of YUI CSS Compressor >=0.9.50.9.5 BSD dparse A parser for Python dependency files >=0.6.20.6.3 MIT license duty A simple task runner. >=0.101.1.0 ISC exceptiongroup Backport of PEP 654 (exception groups) >=1.0.0rc8; python_version < \"3.11\"1.2.0 ? execnet execnet: rapid multi-Python deployment >=1.12.0.2 MIT License failprint Run a command, print its output only if it fails. !=1.0.0,>=0.111.0.2 ISC ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License git-changelog Automatic Changelog generator using Jinja2 templates. >=2.32.4.0 ISC gitdb Git Object Database <5,>=4.0.14.0.11 BSD License gitpython GitPython is a Python library used to interact with Git repositories 3.1.40 BSD htmlmin2 An HTML Minifier >=0.1.130.1.13 BSD idna Internationalized Domain Names in Applications (IDNA) <4,>=2.53.6 BSD License importlib-metadata Read metadata from Python packages >=4.3; python_version < \"3.10\"7.0.1 ? iniconfig brain-dead simple config-ini parsing 2.0.0 MIT License jinja2 A very fast and expressive template engine. <4,>=2.113.1.2 BSD-3-Clause jsmin JavaScript minifier. >=3.0.13.0.1 MIT License markdown Python implementation of John Gruber's Markdown. <4.0.0,>=3.3.33.5.1 BSD License markdown-callouts Markdown extension: a classier syntax for admonitions >=0.30.3.0 MIT markdown-exec Utilities to execute code blocks in Markdown files. >=1.71.8.0 ISC markupsafe Safely add untrusted strings to HTML/XML markup. >=2.02.1.3 BSD-3-Clause mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.51.5.3 BSD License mkdocs-coverage MkDocs plugin to integrate your coverage HTML report into your site. >=1.01.0.0 ISC mkdocs-gen-files MkDocs plugin to programmatically generate documentation pages during the build >=0.50.5.0 MIT License mkdocs-git-committers-plugin-2 An MkDocs plugin to create a list of contributors on the page. The git-committers plugin will seed the template context with a list of GitHub or GitLab committers and other useful GIT info such as last modified date >=1.22.2.3 MIT mkdocs-literate-nav MkDocs plugin to specify the navigation in Markdown instead of YAML >=0.60.6.1 MIT License mkdocs-material Documentation that simply works >=9.49.5.3 MIT License mkdocs-material-extensions Extension pack for Python Markdown and MkDocs Material. ~=1.31.3.1 MIT License mkdocs-minify-plugin An MkDocs plugin to minify HTML, JS or CSS files prior to being written to disk >=0.70.7.2 MIT mypy Optional static typing for Python >=1.51.8.0 MIT mypy-extensions Type system extensions for programs checked with the mypy type checker. >=0.4.31.0.0 MIT License packaging Core utilities for Python packages >=22.023.2 BSD License paginate Divides large result sets into pages for easier browsing ~=0.50.5.6 MIT pathspec Utility library for gitignore style pattern matching of file paths. >=0.9.00.12.1 Mozilla Public License 2.0 (MPL 2.0) platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=24.1.0 MIT License pluggy plugin and hook calling mechanisms for python <2.0,>=0.121.3.0 MIT ptyprocess Run a subprocess in a pseudo terminal ~=0.6; sys_platform != \"win32\"0.7.0 ISC License (ISCL) pygments Pygments is a syntax highlighting package written in Python. ~=2.162.17.2 BSD-2-Clause pymdown-extensions Extension pack for Python Markdown. >=910.7 MIT License pytest pytest: simple powerful testing with Python >=7.47.4.4 MIT pytest-cov Pytest plugin for measuring coverage. >=4.14.1.0 MIT pytest-randomly Pytest plugin to randomly order tests and control random.seed. >=3.153.15.0 MIT pytest-xdist pytest xdist plugin for distributed testing, most importantly across multiple CPUs >=3.33.5.0 MIT python-dateutil Extensions to the standard Python datetime module >=2.8.12.8.2 Dual License pytz World timezone definitions, modern and historical >=2015.7; python_version < \"3.9\"2023.3.post1 ? pyyaml YAML parser and emitter for Python >=5.16.0.1 MIT pyyaml-env-tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License regex Alternative regular expression module, to replace re. >=2022.42023.12.25 Apache Software License requests Python HTTP for Humans. 2.31.0 Apache 2.0 ruamel-yaml ruamel.yaml is a YAML parser/emitter that supports roundtrip preservation of comments, seq/map flow style, and map key order >=0.17.210.18.5 MIT license ruamel-yaml-clib C version of reader, parser and emitter for ruamel.yaml derived from libyaml >=0.2.7; platform_python_implementation == \"CPython\" and python_version < \"3.13\"0.2.8 MIT ruff An extremely fast Python linter and code formatter, written in Rust. >=0.00.1.11 MIT safety Checks installed dependencies for known vulnerabilities and licenses. >=2.32.3.4 MIT license semver Python helper for Semantic Versioning (https://semver.org) >=2.133.0.2 BSD setuptools Easily download, build, install, upgrade, and uninstall Python packages >=19.369.0.3 MIT License six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT smmap A pure Python implementation of a sliding window memory map manager <6,>=3.0.15.0.1 BSD tomli A lil' TOML parser >=2.0; python_version < '3.11'2.0.1 ? types-markdown Typing stubs for Markdown >=3.53.5.0.20240106 Apache-2.0 license types-pyyaml Typing stubs for PyYAML >=6.06.0.12.12 Apache-2.0 license typing-extensions Backported and Experimental Type Hints for Python 3.8+ >=4.0.1; python_version < \"3.11\"4.9.0 Python Software Foundation License urllib3 HTTP library with thread-safe connection pooling, file post, and more. <3,>=1.21.12.1.0 MIT License watchdog Filesystem events monitoring >=2.03.0.0 Apache License 2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.17.0 ?
ISC License\n\nCopyright (c) 2021, Timoth\u00e9e Mazzucotelli\n\nPermission to use, copy, modify, and/or distribute this software for any\npurpose with or without fee is hereby granted, provided that the above\ncopyright notice and this permission notice appear in all copies.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES\nWITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF\nMERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR\nANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES\nWHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN\nACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF\nOR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.\n
mkdocstrings-python follows the sponsorware release strategy, which means that new features are first exclusively released to sponsors as part of Insiders. Read on to learn what sponsorships achieve, how to become a sponsor to get access to Insiders, and what's in it for you!
"},{"location":"insiders/#what-is-insiders","title":"What is Insiders?","text":"
mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1 all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time \u2013 a very scarce resource \u2013 which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships.
"},{"location":"insiders/#whats-in-it-for-me","title":"What's in it for me?","text":"
The moment you become a sponsor, you'll get immediate access to 4 additional features that you can start using right away, and which are currently exclusively available to sponsors:
Automatic rendering of function signature overloads
Auto-summary of object members
griffe-typing-deprecated \u2014 [Project] Griffe extension for @typing.deprecated (PEP 702)
griffe-pydantic \u2014 [Project] Griffe extension for Pydantic
"},{"location":"insiders/#how-to-become-a-sponsor","title":"How to become a sponsor","text":"
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to pawamoy@pm.me with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
You can cancel your sponsorship anytime.5
\u00a0 Join our awesome sponsors
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
"},{"location":"insiders/#1000-gravifridge-user-manual","title":"$ 1,000 \u2014 GraviFridge User Manual","text":"
Auto-summary of object members
Automatic rendering of function signature overloads
griffe-pydantic \u2014 [Project] Griffe extension for Pydantic
griffe-typing-deprecated \u2014 [Project] Griffe extension for @typing.deprecated (PEP 702)
This section lists all funding goals that were previously completed, which means that those features were part of Insiders, but are now generally available and can be used by all users.
"},{"location":"insiders/#exec-5--500-plasmavac-user-guide","title":"$ 500 \u2014 PlasmaVac User Guide","text":"
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings \u2014 [Project] Griffe extension for inheriting docstrings
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to pawamoy@pm.me.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python.\u00a0\u21a9
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability.\u00a0\u21a9
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly.\u00a0\u21a9
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to pawamoy@pm.me, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations.\u00a0\u21a9
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable.\u00a0\u21a9
"},{"location":"insiders/changelog/","title":"Changelog","text":""},{"location":"insiders/changelog/#mkdocstrings-python-insiders","title":"mkdocstrings-python Insiders","text":""},{"location":"insiders/changelog/#1.5.1","title":"1.5.1 September 12, 2023","text":"
Prevent empty auto-summarized Methods section.
"},{"location":"insiders/changelog/#1.5.0","title":"1.5.0 September 05, 2023","text":"
Render function signature overloads.
"},{"location":"insiders/changelog/#1.4.0","title":"1.4.0 August 27, 2023","text":"
Render cross-references in attribute signatures.
"},{"location":"insiders/changelog/#1.3.0","title":"1.3.0 August 24, 2023","text":"
Add \"method\" symbol type.
"},{"location":"insiders/changelog/#1.2.0","title":"1.2.0 August 20, 2023","text":"
Add member auto-summaries.
"},{"location":"insiders/changelog/#1.1.4","title":"1.1.4 July 17, 2023","text":"
Fix heading level increment for class members.
"},{"location":"insiders/changelog/#1.1.3","title":"1.1.3 July 17, 2023","text":"
Fix heading level (avoid with clause preventing to decrease it).
"},{"location":"insiders/changelog/#1.1.2","title":"1.1.2 July 15, 2023","text":"
Use non-breaking spaces after symbol types.
"},{"location":"insiders/changelog/#1.1.1","title":"1.1.1 June 27, 2023","text":"
Correctly escape expressions in signatures and other rendered types.
"},{"location":"insiders/changelog/#1.1.0","title":"1.1.0 June 4, 2023","text":"
Add Symbol types in headings and table of contents.
"},{"location":"insiders/changelog/#1.0.0","title":"1.0.0 May 10, 2023","text":"
Add cross-references for type annotations in signatures. Make sure to update your local templates as the signature of the format_signature filter has changed. The templates that must be updated: class.html, expression.html, function.html and signature.html.
"},{"location":"insiders/installation/","title":"Getting started with Insiders","text":"
mkdocstrings-python Insiders is a compatible drop-in replacement for mkdocstrings-python, and can be installed similarly using pip or git. Note that in order to access the Insiders repository, you need to become an eligible sponsor of @pawamoy on GitHub.
PyPI Insiders is a tool that helps you keep up-to-date versions of Insiders projects in the PyPI index of your choice (self-hosted, Google registry, Artifactory, etc.).
The GH_TOKEN environment variable is a GitHub token. It can be obtained by creating a personal access token for your GitHub account. It will give you access to the Insiders repository, programmatically, from the command line or GitHub Actions workflows:
Go to https://github.com/settings/tokens
Click on Generate a new token
Enter a name and select the repo scope
Generate the token and store it in a safe place
Note that the personal access token must be kept secret at all times, as it allows the owner to access your private repositories.
Self-hosting the Insiders package makes it possible to depend on mkdocstrings-python normally, while transparently downloading and installing the Insiders version locally. It means that you can specify your dependencies normally, and your contributors without access to Insiders will get the public version, while you get the Insiders version on your machine.
Limitation
With this method, there is no way to force the installation of an Insiders version rather than a public version. If there is a public version that is more recent than your self-hosted Insiders version, the public version will take precedence. Remember to regularly update your self-hosted versions by uploading latest distributions.
You can build the distributions for Insiders yourself, by cloning the repository and using build to build the distributions, or you can download them from our GitHub Releases. You can upload these distributions to a private PyPI-like registry (Artifactory, Google Cloud, pypiserver, etc.) with Twine:
# download distributions in ~/dists, then upload with:\ntwine upload --repository-url https://your-private-index.com ~/dists/*\n
You might also need to provide a username and password/token to authenticate against the registry. Please check Twine's documentation.
You can then configure pip (or other tools) to look for packages into your package index. For example, with pip:
pip config set global.extra-index-url https://your-private-index.com/simple\n
Note that the URL might differ depending on whether your are uploading a package (with Twine) or installing a package (with pip), and depending on the registry you are using (Artifactory, Google Cloud, etc.). Please check the documentation of your registry to learn how to configure your environment.
We kindly ask that you do not upload the distributions to public registries, as it is against our Terms of use.
Full example with pypiserver
In this example we use pypiserver to serve a local PyPI index.
pip install --user pypiserver\n# or pipx install pypiserver\n\n# create a packages directory\nmkdir -p ~/.local/pypiserver/packages\n\n# run the pypi server without authentication\npypi-server run -p 8080 -a . -P . ~/.local/pypiserver/packages &\n
We can configure the credentials to access the server in ~/.pypirc:
We then clone the Insiders repository, build distributions and upload them to our local server:
# clone the repository\ngit clone git@github.com:pawamoy-insiders/mkdocstrings-python\ncd python\n\n# install build\npip install --user build\n# or pipx install build\n\n# checkout latest tag\ngit checkout $(git describe --tags --abbrev=0)\n\n# build the distributions\npyproject-build\n\n# upload them to our local server\ntwine upload -r local dist/* --skip-existing\n
Finally, we configure pip, and for example PDM, to use our local index to find packages:
pip config set global.extra-index-url http://localhost:8080/simple\npdm config pypi.extra.url http://localhost:8080/simple\n
Now when running pip install mkdocstrings-python, or resolving dependencies with PDM, both tools will look into our local index and find the Insiders version. Remember to update your local index regularly!
When upgrading Insiders, you should always check the version of mkdocstrings-python which makes up the first part of the version qualifier. For example, a version like 8.x.x.4.x.x means that Insiders 4.x.x is currently based on 8.x.x.
If the major version increased, it's a good idea to consult the changelog and go through the steps to ensure your configuration is up to date and all necessary changes have been made.
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See parsers under griffe.docstrings.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
Filters to apply, based on members' names. Each element is a tuple: a pattern, and a boolean indicating whether to reject the object if the pattern matches.
An optional, explicit list of members to keep. When given and empty, return an empty list. When given and not empty, ignore filters and docstrings presence/absence.
You can install this handler as a mkdocstrings extra:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings[python]>=0.18\",\n]\n
You can also explicitly depend on the handler:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings-python\",\n]\n
The Python handler is the default mkdocstrings handler. You can change the default handler, or explicitely set the Python handler as default by defining the default_handler configuration option of mkdocstrings in mkdocs.yml:
With the Python handler installed and configured as default handler, you can inject documentation for a module, class, function, or any other Python object with mkdocstrings' autodoc syntax, in your Markdown pages:
::: path.to.object\n
If another handler was defined as default handler, you can explicitely ask for the Python handler to be used when injecting documentation with the handler option:
This option is used to import Sphinx-compatible objects inventories from other documentation sites. For example, you can import the standard library objects inventory like this:
When importing an inventory, you enable automatic cross-references to other documentation sites like the standard library docs or any third-party package docs. Typically, you want to import the inventories of your project's dependencies, at least those that are used in the public API.
See mkdocstrings' documentation on inventories for more details.
Additionally, the Python handler accepts a domains option in the import items, which allows to select the inventory domains to select. By default the Python handler only selects the py domain (for Python objects). You might find useful to also enable the std domain:
This option is used to provide filesystem paths in which to search for Python modules. Non-absolute paths are computed as relative to MkDocs configuration file. Example:
mkdocs.yml
plugins:\n- mkdocstrings:\n handlers:\n python:\n paths: [src] # search packages in the src folder\n
This option allows resolving aliases (imports) to any external module. Modules are considered external when they are not part of the package your are injecting documentation for. Enabling this option will tell the handler to resolve aliases recursively when they are made public through the __all__ variable.
Use with caution
This can load a lot of modules through Griffe, slowing down your build or triggering errors that Griffe does not yet handle. We recommend using the preload_modules option instead, which acts as an include-list rather than as include-all.
These options affect how the documentation is collected from sources and rendered. See the following tables summarizing the options, and get more details for each option in the following pages:
General options: various options that do not fit in the other categories
Headings options: options related to headings and the table of contents (or sidebar, depending on the theme used)
Members options: options related to filtering or ordering members in the generated documentation
Docstrings options: options related to docstrings (parsing and rendering)
Signature options: options related to signatures and type annotations
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See parsers under griffe.docstrings.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
There are multiple ways to tell the handler where to find your packages/modules.
The recommended method is to use the paths option, as it's the only one that works with the -f option of MkDocs, allowing to build the documentation from any location on the file system. Indeed, the paths provided with the paths option are computed as relative to the configuration file (mkdocs.yml), so that the current working directory has no impact on the build process: you can build the docs from any location on your filesystem.
"},{"location":"usage/#using-the-paths-option","title":"Using the paths option","text":"
Except for case 1, which is supported by default, we strongly recommend setting the path to your packages using this option, even if it works without it (for example because your project manager automatically adds src to PYTHONPATH), to make sure anyone can build your docs from any location on their filesystem.
"},{"location":"usage/#using-the-pythonpath-environment-variable","title":"Using the PYTHONPATH environment variable","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
You can take advantage of the usual Python loading mechanisms. In Bash and other shells, you can run your command like this (note the prepended PYTHONPATH=...):
"},{"location":"usage/#installing-your-package-in-the-current-python-environment","title":"Installing your package in the current Python environment","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
Install your package in the current environment, and run MkDocs:
You can customize the colors of the symbol types (see show_symbol_type_heading and show_symbol_type_toc) by overriding the values of our CSS variables, for example:
The [data-md-color-scheme=\"*\"] selectors work with the Material for MkDocs theme. If you are using another theme, adapt the selectors to this theme if it supports light and dark themes, otherwise just override the variables at root level:
See them in the repository. See the general mkdocstrings documentation to learn how to override them: https://mkdocstrings.github.io/theming/#templates.
Each one of these templates extends a base version in theme/_base. Example:
theme/class.html
{% extends \"_base/class.html\" %}\n
Some of these templates define Jinja blocks. allowing to customize only parts of a template without having to fully copy-paste it into your project:
Only the templates for the Material for MkDocs provide Jinja blocks. The following tables show the block names, description, and the Jinja context available in their scope.
"},{"location":"usage/extensions/","title":"Extensions","text":""},{"location":"usage/extensions/#work-in-progress","title":"Work in Progress!","text":"
The Python handler supports extensions through mkdocstrings' handler extensions.
Specifically, additional templates can be added to the handler, and Griffe extensions can instruct the handler to use a particular template for a particular object by setting a value in the Griffe object's extra dictionary:
griffe_extension.py
obj = ... # get a reference to a Griffe object\nif \"mkdocstrings\" not in obj.extra:\n obj.extra[\"mkdocstrings\"] = {}\nobj.extra[\"mkdocstrings\"][\"template\"] = \"template_name.html\"\n
Every style gets rendered the same way. Here are some docstring examples.
GoogleNumpySphinx
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters:\n name: The name of the person to greet.\n\n Returns:\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters\n ----------\n name\n The name of the person to greet.\n\n Returns\n -------\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n :param name: The name of the person to greet.\n :return: A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
A section is a block of text that has a special meaning in a docstring. There are sections for documenting attributes of an object, parameters of a function, exceptions raised by a function, the return value of a function, etc.
Sections are parsed as structured data and can therefore be rendered in different ways. Possible values:
\"table\": a simple table, usually with type, name and description columns
\"list\": a simple list, akin to what you get with the ReadTheDocs Sphinx theme
\"spacy\": a poor implementation of the amazing tables in Spacy's documentation
Tables work well when you have lots of items with short names, type annotations, descriptions, etc.. With longer strings, the columns risk getting squished horizontally. In that case, the Spacy tables can help.
Parameters:
Type Name Description Default intthreshold Threshold for something. required boolflag Enable something. False
Other Parameters:
Type Name Description Default list[int | float]gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. required VacuumType | Literal[\"regular\"]vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. VacuumType.PLASMA
Lists work well whatever the length of names, type annotations, descriptions, etc.
Parameters:
threshold (int) \u2014 Threshold for something.
flag (bool) \u2014 Enable something.
Other Parameters:
gravity_forces (list[int | float]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
vacuum_type (VacuumType | Literal[\"regular\"]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Spacy tables work better than regular tables with longer names, type annotations, descriptions, etc., by reserving more horizontal space on the second column.
Parameters:
Name Description threshold Threshold for something.TYPE: int DEFAULT: required flag Enable something.TYPE: bool DEFAULT: False
Other Parameters:
Name Description gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE: list[int | float] DEFAULT: required vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE:VacuumType | Literal[\"regular\"] DEFAULT: VacuumType.PLASMA"},{"location":"usage/configuration/docstrings/#merge_init_into_class","title":"merge_init_into_classThing(value=0)Thing","text":"
Type boolFalse
Whether to merge the __init__ method into the class' signature and docstring.
By default, only the class name is rendered in headings. When merging, the __init__ method parameters are added after the class name, like a signature, and the __init__ method docstring is appended to the class' docstring. This option is well used in combination with the ignore_init_summary docstring option, to discard the first line of the __init__ docstring which is not often useful.
class Thing:\n \"\"\"A class for things.\"\"\"\n\n def __init__(self, value: int = 0):\n \"\"\"Initialize a thing.\n\n Parameters:\n value: The thing's value.\n \"\"\"\n self.value = value\n
Preview
Merged, summary discardedUnmerged, summary kept
Class docstring.
Parameters:
Type Name Description Default intvalue The thing's value. 0
Class docstring.
__init__(value=0)
Initialize a thing.
Parameters:
Type Name Description Default intvalue The thing's value. 0"},{"location":"usage/configuration/docstrings/#show_if_no_docstring","title":"show_if_no_docstringfunction_without_docstringfunction_with_docstringClassWithoutDocstringfunction_with_docstringClassWithoutDocstring","text":"
Type boolFalse
Show the object heading even if it has no docstring or children with docstrings.
Without an explicit list of members, members are selected based on filters, and then filtered again to keep only those with docstrings. Checking if a member has a docstring is done recursively: if at least one of its direct or indirect members (lower in the tree) has a docstring, the member is rendered. If the member does not have a docstring, and none of its members have a docstring, it is excluded.
With this option you can tell the Python handler to skip the docstring check.
class Class:\n \"\"\"Summary.\n\n Long description.\n\n Warning: Deprecated\n Stop using this class.\n\n Attributes:\n attr: Some attribute.\n \"\"\"\n\n attr: int = 1\n
Preview
With description blocksWithout description blocks
Summary.
Long description.
Deprecated
Stop using this class.
Attributes:
Type Name Description intattr Some attribute.
Attributes:
Type Name Description intattr Some attribute."},{"location":"usage/configuration/docstrings/#show_docstring_examples","title":"show_docstring_examplesprint_helloprint_hello","text":"
Type boolTrue
Whether to render the \"Examples\" section of docstrings.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Receives:\n skip: Number of elements to skip.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
def warn():\n \"\"\"Warn user.\n\n Warns:\n UserWarning: When this is inappropriate.\n \"\"\"\n warnings.warn(UserWarning(\"This is inappropriate\"))\n
Preview
With warningsWithout warnings
Warn user.
Warns:
Type Description UserWarning When this is inappropriate.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Yields:\n Elements of the iterable.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
Whether to allow inspecting modules (importing them) when it is not possible to visit them (parse their source code).
When loading data for a given package, Griffe discovers every Python module, compiled or not, and inspects or visits them accordingly.
If you have compiled modules but also provide stubs for them, you might want to disable the inspection of these modules, because inspection picks up many more members, and sometimes the collected data is inaccurate (depending on the tool that was used to compile the module) or too low-level/technical for API documentation.
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module. The package from which the imported object originates must be accessible to the handler (see Finding modules).
When injecting documentation for an object, the object itself and its members are rendered. For each layer of objects, we increase the heading level by 1.
The initial heading level will be used for the first layer. If you set it to 3, then headings will start with <h3>.
If the heading for the root object is not shown, then the initial heading level is used for its members.
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::).
It is pretty common to inject documentation for one module per page, especially when following our automatic reference pages recipe. Since each page already has a title, usually being the module's name, we can spare one heading level by not showing the heading for the module itself (heading levels are limited to 6 by the HTML specification).
Sparing that extra level can be helpful when your objects tree is deeply nested (e.g. method in a class in a class in a module). If your objects tree is not deeply nested, and you are injecting documentation for many different objects on a single page, it might be preferable to render the heading of each object.
If the root heading is not shown, at least add a ToC entry for it.
If you inject documentation for an object in the middle of a page, after long paragraphs, and without showing the root heading, then you will not be able to link to this particular object as it won't have a permalink and will be \"lost\" in the middle of text. In that case, it is useful to add a hidden anchor to the document, which will also appear in the table of contents.
In other cases, you might want to disable the entry to avoid polluting the ToC. It is not possible to show the root heading and hide the ToC entry.
Show the full Python path for the root object heading.
The path of a Python object is the dot-separated list of names under which it is accessible, for example package.module.Class.method.
With this option you can choose to show the full path of the object you inject documentation for, or just its name. This option impacts only the object you specify, not its members. For members, see the two other options show_root_members_full_path and show_object_full_path.
Same as for show_root_members_full_path, but for every member, recursively. This option takes precedence over show_root_members_full_path:
show_root_members_full_pathshow_object_full_path Direct root members path False False Name only False True Full True False Full True True Full in mkdocs.yml (global configuration)
When grouped by categories, show a heading for each category. These category headings will appear in the table of contents, allowing you to link to them using their permalinks.
Not recommended with deeply nested object
When injecting documentation for deeply nested objects, you'll quickly run out of heading levels, and the objects at the bottom of the tree risk all getting documented using H6 headings, which might decrease the readability of your API docs.
Only members declared in this list will be rendered. A member without a docstring will still be rendered, even if show_if_no_docstring is set to false.
The members will be rendered in the specified order, regardless of the value of members_order.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every member.
Any given value, except for an explicit None (null in YAML) will tell the handler to ignore filters for the object's members. Filters will still be applied to the next layers of members (grand-children).
An explicit list of inherited members (for classes) to render.
Inherited members are always fetched from classes that are in the same package as the currently rendered class. To fetch members inherited from base classes, themselves coming from external packages, use the preload_modules option. For example, if your class inherits from Pydantic's BaseModel, and you want to render BaseModel's methods in your class, use preload_modules: [pydantic]. The pydantic package must be available in the current environment.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any inherited member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every inherited member.
When all inherited members are selected with inherited_members: true, it is possible to specify both members and inherited members in the members list:
In this case, only declared members will be subject to further filtering with filters and docstrings.
inherited_members: true # (1)\n# members: null\n
In this case, both declared and inherited members will be subject to further filtering with filters and docstrings.
You can render all declared members and all or specific inherited members, avoiding further filtering with filters and docstrings by setting members: true:
A list of filters applied to filter objects based on their name.
Filters are regular expressions. These regular expressions are evaluated by Python and so must match the syntax supported by the re module. A filter starting with ! (negative filter) will exclude matching objects instead of including them.
The default value ([\"!^_[^_]\"]) means: render every object, except those starting with one underscore, unless they start with two underscores. It means that an object whose name is hello, __hello, or __hello__ will be rendered, but not one whose name is _hello.
Each filter takes precedence over the previous one. This allows for fine-grain selection of objects by adding more specific filters. For example, you can start by unselecting objects that start with _, and add a second filter that re-select objects that start with __. The default filters can therefore be rewritten like this:
filters:\n- \"!^_\"\n- \"^__\"\n
If there are no negative filters, the handler considers that everything is unselected first, and then selects things based on your positive filters. If there is at least one negative filter, the handler considers that everything is selected first, and then re-selects/unselects things based on your other filters. In short, filters: [\"a\"] means \"keep nothing except names containing a\", while filters: [\"!a\"] means \"keep everything except names containing a\".
An empty list of filters tells the Python handler to render every object. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy).
Group the object members by categories: attributes, classes, functions, and modules.
Members within a same category will be ordered according to the members_order option. You can use the show_category_heading option to also render a heading for each category.
When rendering a module, show its submodules recursively.
This is false by default, because most of the time we render only one module per page, and when rendering a package (a tree of modules and their members) on a single page, we quickly run out of heading levels.
Whether to render summaries of modules, classes, functions (methods) and attributes.
This option accepts a boolean (yes, true, no, false in YAML) or a dictionary with one or more of the following keys: attributes, functions, classes, modules, with booleans as values. Class methods summary is (de)activated with the functions key. By default, summary is false, and by extension all values are false.
Summaries will be rendered as the corresponding docstring sections. For example, the summary for attributes will be rendered as an Attributes docstring section. The section will be rendered in accordance with the docstring_section_style option. If the objects appearing in the summary are also rendered on the page (or somewhere else on the site), their name will automatically link to their rendered documentation.
brief (recommended): render only the last component of each type path, not their full paths. For example, it will render Sequence[Path] and not typing.Sequence[pathlib.Path]. Brief annotations will cross-reference the right object anyway, and show the full path in a tooltip when hovering them.
source: render annotations as written in the source. For example if you imported typing as t, it will render typing.Sequence as t.Sequence. Each part will cross-reference the relevant object: t will link to the typing module and Sequence will link to the Sequence type.
full: render annotations with their full path (the opposite of brief). For example if you import Sequence and Pattern from typing and annoate something using Sequence[Pattern], it will render as typing.Sequence[typing.Pattern], with each part cross-referencing the corresponding object.
import markdown\nimport markupsafe\n\n\ndef convert(text: str, md: markdown.Markdown) -> markupsafe.Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return markupsafe.Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
import markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: markdown.Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
from markdown import Markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description markupsafe.Markuptext Converted markup."},{"location":"usage/configuration/signatures/#line_length","title":"line_lengthlong_function_namelong_function_name","text":"
Type int60
Maximum line length when formatting code/signatures.
When separating signatures from headings with the separate_signature option, the Python handler will try to format the signatures using Black and the specified line length.
If Black is not installed, the handler issues an INFO log once.
Whether to render cross-references for type annotations in signatures.
When signatures are separated from headings with the separate_signature option and type annotations are shown with the show_signature_annotations option, this option will render a cross-reference (link) for each type annotation in the signature.
"},{"location":"usage/docstrings/google/","title":"Google style","text":""},{"location":"usage/docstrings/google/#work-in-progress","title":"Work in Progress!","text":""},{"location":"usage/docstrings/google/#google-style-admonitions","title":"Google-style admonitions","text":"
With Google-style docstrings, any section that is not recognized will be transformed into its admonition equivalent. For example:
DocstringResult
\"\"\"\nNote:\n It looks like a section, but it will be rendered as an admonition.\n\nTip: You can even choose a title.\n This admonition has a custom title!\n\"\"\"\n
Note
It looks like a section, but it will be rendered as an admonition.
You can even choose a title.
This admonition has a custom title!
See Napoleon's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/numpy/","title":"Numpydoc style","text":""},{"location":"usage/docstrings/numpy/#work-in-progress","title":"Work in Progress!","text":"
Note
As Numpy-style is partially supported by the underlying parser, you may experience problems in the building process if your docstring has a Methods section in the class docstring (see #366).
See Numpydoc's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/sphinx/","title":"Sphinx style","text":""},{"location":"usage/docstrings/sphinx/#work-in-progress","title":"Work in Progress!","text":"
See Sphinx's documentation. See the supported docstring sections on Griffe's documentation.
"}]}
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 55d1b2dbaf07bcd61405dd26d1b1188a8710f06e..e31596086dd342615b2ee1bb7a98697f5beba09e 100644
GIT binary patch
delta 15
WcmZ3%yn>lczMF%?PkkfXB1QlpLIdUi
delta 15
WcmZ3%yn>lczMF$1Mr9-0B1QlphXe5d