# Buildsheet autogenerated by ravenadm tool -- Do not edit. NAMEBASE= python-annotated-doc VERSION= 0.0.5 KEYWORDS= python VARIANTS= v13 v14 SDESC[v13]= Annotate class and code attributes (3.13) SDESC[v14]= Annotate class and code attributes (3.14) HOMEPAGE= https://github.com/fastapi/annotated-doc CONTACT= Python_Automaton[python@ravenports.com] DOWNLOAD_GROUPS= main SITES[main]= PYPIWHL/3e/30/e900b21425a860e195f32e37657aa1f7c7f2b1bfb26f03ca209b90933c06 DISTFILE[1]= annotated_doc-0.0.5-py3-none-any.whl:main DIST_SUBDIR= python-src DF_INDEX= 1 SPKGS[v13]= single SPKGS[v14]= single OPTIONS_AVAILABLE= PY313 PY314 OPTIONS_STANDARD= none VOPTS[v13]= PY313=ON PY314=OFF VOPTS[v14]= PY313=OFF PY314=ON DISTNAME= annotated_doc-0.0.5.dist-info GENERATED= yes [PY313].USES_ON= python:v13,wheel [PY314].USES_ON= python:v14,wheel [FILE:2482:descriptions/desc.single] # Annotated Doc Document parameters, class attributes, return types, and variables inline, with `Annotated`. [image] [image] [image] [image] ## Installation ```bash pip install annotated-doc ``` Or with `uv`: ```Python uv add annotated-doc ``` ## Usage Import `Doc` and pass a single literal string with the documentation for the specific parameter, class attribute, return type, or variable. For example, to document a parameter `name` in a function `hi` you could do: ```Python from typing import Annotated from annotated_doc import Doc def hi(name: Annotated[str, Doc("Who to say hi to")]) -> None: print(f"Hi, {name}!") ``` You can also use it to document class attributes: ```Python from typing import Annotated from annotated_doc import Doc class User: name: Annotated[str, Doc("The user's name")] age: Annotated[int, Doc("The user's age")] ``` The same way, you could document return types and variables, or anything that could have a type annotation with `Annotated`. ## Who Uses This `annotated-doc` was made for: * [FastAPI] * [Typer] * [SQLModel] * [Asyncer] `annotated-doc` is supported by [griffe-typingdoc], which powers reference documentation like the one in the [FastAPI Reference]. ## Reasons not to use `annotated-doc` You are already comfortable with one of the existing docstring formats, like: * Sphinx * numpydoc * Google * Keras Your team is already comfortable using them. You prefer having the documentation about parameters all together in a docstring, separated from the code defining them. You care about a specific set of users, using one specific editor, and that editor already has support for the specific docstring format you use. ## Reasons to use `annotated-doc` * No micro-syntax to learn for newcomers, it’s **just Python** syntax. * **Editing** would be already fully supported by default by any editor (current or future) supporting Python syntax, including syntax errors, syntax highlighting, etc. * **Rendering** would be relatively straightforward to implement by static tools (tools that don't need runtime execution), as the information can be extracted from the AST they normally already create. * **Deduplication of information**: the name of a parameter would be defined in a single place, not duplicated inside of a docstring. * **Elimination** of the possibility of having **inconsistencies** when removing a parameter or class variable and **forgetting to remove** its [FILE:126:distinfo] 117bac03a25ede5df5440e855b32d556049ca169ead221505badf432fed4b101 5302 python-src/annotated_doc-0.0.5-py3-none-any.whl