111

Is it posible to use docstring for plain variable? For example I have module called t

def f():
    """f"""

l = lambda x: x
"""l"""

and I do

>>> import t
>>> t.f.__doc__
'f'

but

>>> t.l.__doc__
>>> 

Example is similar to PEP 258's (search for "this is g").

alexanderkuk
  • 1,551
  • 2
  • 12
  • 29
  • 13
    PEP 258 was rejected. – Tim Pietzcker Jan 11 '12 at 13:44
  • 3
    Possible duplicate of [How to document fields and properties in Python?](https://stackoverflow.com/questions/6060813/how-to-document-fields-and-properties-in-python) – Stevoisiak Oct 27 '17 at 19:03
  • do you want to add a docstring to a variable, or just documentation referring to a variable that e.g. sphinx can parse and present in a useful way? – joel Sep 05 '19 at 11:41

10 Answers10

114

Use typing.Annotated to provide a docstring for variables.

I originally wrote an answer (see below) where I said this wasn't possible. That was true back in 2012 but Python has moved on. Today you can provide the equivalent of a docstring for a global variable or an attribute of a class or instance. You will need to be running at least Python 3.9 for this to work:

from __future__ import annotations
from typing import Annotated

Feet = Annotated[float, "feet"]
Seconds = Annotated[float, "seconds"]
MilesPerHour = Annotated[float, "miles per hour"]

day: Seconds = 86400
legal_limit: Annotated[MilesPerHour, "UK national limit for single carriageway"] = 60
current_speed: MilesPerHour

def speed(distance: Feet, time: Seconds) -> MilesPerHour:
    """Calculate speed as distance over time"""
    fps2mph = 3600 / 5280  # Feet per second to miles per hour
    return distance / time * fps2mph

You can access the annotations at run time using typing.get_type_hints():

Python 3.9.1 (default, Jan 19 2021, 09:36:39) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import calc
>>> from typing import get_type_hints
>>> hints = get_type_hints(calc, include_extras=True)
>>> hints
{'day': typing.Annotated[float, 'seconds'], 'legal_limit': typing.Annotated[float, 'miles per hour', 'UK national limit for single carriageway'], 'current_speed': typing.Annotated[float, 'miles per hour']}

Extract information about variables using the hints for the module or class where they were declared. Notice how the annotations combine when you nest them:

>>> hints['legal_limit'].__metadata__
('miles per hour', 'UK national limit for single carriageway')
>>> hints['day']
typing.Annotated[float, 'seconds']

It even works for variables that have type annotations but have not been assigned a value. If I tried to reference calc.current_speed I would get an attribute error but I can still access its metadata:

>>> hints['current_speed'].__metadata__
('miles per hour',)

The type hints for a module only include the global variables, to drill down you need to call get_type_hints() again on functions or classes:

>>> get_type_hints(calc.speed, include_extras=True)
{'distance': typing.Annotated[float, 'feet'], 'time': typing.Annotated[float, 'seconds'], 'return': typing.Annotated[float, 'miles per hour']}

I only know of one tool so far that can use typing.Annotated to store documentation about a variable and that is Pydantic. It is slightly more complicated than just storing a docstring though it actually expects an instance of pydantic.Field. Here's an example:

from typing import Annotated
import typing_extensions
from pydantic import Field
from pydantic.main import BaseModel
from datetime import date

# TypeAlias is in typing_extensions for Python 3.9:
FirstName: typing_extensions.TypeAlias = Annotated[str, Field(
        description="The subject's first name", example="Linus"
    )]

class Subject(BaseModel):
    # Using an annotated type defined elsewhere:
    first_name: FirstName = ""

    # Documenting a field inline:
    last_name: Annotated[str, Field(
        description="The subject's last name", example="Torvalds"
    )] = ""

    # Traditional method without using Annotated
    # Field needs an extra argument for the default value
    date_of_birth: date = Field(
        ...,
        description="The subject's date of birth",
        example="1969-12-28",
    )

Using the model class:

>>> guido = Subject(first_name='Guido', last_name='van Rossum', date_of_birth=date(1956, 1, 31))
>>> print(guido)
first_name='Guido' last_name='van Rossum' date_of_birth=datetime.date(1956, 1, 31)

Pydantic models can give you a JSON schema:

>>> from pprint import pprint
>>> pprint(Subject.schema())
{'properties': {'date_of_birth': {'description': "The subject's date of birth",
                                  'example': '1969-12-28',
                                  'format': 'date',
                                  'title': 'Date Of Birth',
                                  'type': 'string'},
                'first_name': {'default': '',
                               'description': "The subject's first name",
                               'example': 'Linus',
                               'title': 'First Name',
                               'type': 'string'},
                'last_name': {'default': '',
                              'description': "The subject's last name",
                              'example': 'Torvalds',
                              'title': 'Last Name',
                              'type': 'string'}},
 'required': ['date_of_birth'],
 'title': 'Subject',
 'type': 'object'}
>>> 

If you use this class in a FastAPI application the OpenApi specification has example and description for all three of these taken from the relevant Field.

And here's the original answer which was true back then but hasn't stood the test of time:

No, it is not possible and it wouldn't be useful if you could.

The docstring is always an attribute of an object (module, class or function), not tied to a specific variable.

That means if you could do:

t = 42
t.__doc__ = "something"  # this raises AttributeError: '__doc__' is read-only

you would be setting the documentation for the integer 42 not for the variable t. As soon as you rebind t you lose the docstring. Immutable objects such as numbers of strings sometimes have a single object shared between different users, so in this example you would probably actually have set the docstring for all occurences of 42 throughout your program.

print(42 .__doc__) # would print "something" if the above worked!

For mutable objects it wouldn't necessarily be harmful but would still be of limited use if you rebind the object.

If you want to document an attribute of a class then use the class's docstring to describe it.

Duncan
  • 92,073
  • 11
  • 122
  • 156
  • 8
    @alexanderkuk: This answer is better than mine. You should accept it instead. – Tim Pietzcker Jan 11 '12 at 14:27
  • 31
    "No, and it wouldn't be useful if you could." It would be if variables weren't implemented this way. – endolith Nov 04 '15 at 16:44
  • 13
    *it wouldn't be useful if you could* -- Why not? If my module uses symbols, how am I supposed to document them? This way the *DATA* section of pydoc is half useful. – Alois Mahdal Jul 30 '16 at 03:24
  • @AloisMahdal the rest of my answer is explaining why it wouldn't be useful: a docstring is attached to a specific object. In the case of a class method you usually access it through the class and don't share it with other classes so it makes sense. A docstring attached to a value such as a number is then visible in all the places that particular number is used. So use a docstring on a class to describe the attributes, don't try to attach the docstring to values like `True` or `False`. – Duncan Jul 31 '16 at 08:58
  • 5
    The real reason why it wouldn't be useful is that the docstring is a property of an object rather than a symbol in a certain context (e.g., a key in a dict, a "member" of a class or a "member" of a module). This is a somewhat flawed design of docstrings, but, of course, pointing this out doesn't help or make this answer less correct. A practical solution would be to put the documentation into the docstring of the module. – Florian Winter Nov 07 '16 at 15:41
  • 5
    I find it more relatable to say that it would be useful if you could attach documentation to members, but that the design of Python docstrings does not really let you do it. – zneak Oct 11 '18 at 00:46
  • As others said, the Issue seems to be that Python has Runtime-Support for docstrings (whats the reasons for that anyways?). If that were not the case but the Docstrings just implemented by static code analysis, docstrings for variables wouldnt just be possible but also very useful. I.e. when I have a huge and complicated API with Typescript I can with a few tricks add docstrings to function parameters - I dont know how much of that is standardized but it works in vscode -. And in general that is helpful, because then you dont have to have either super long variable names or non-descript shorts – Sam96 Nov 04 '19 at 18:49
  • The argument here is somewhat put into question by the existence of variable type annotations, implemented by a module-level `__annotations__` dictionary. Of course module-level `__doc__` is already taken, but there could be a dictionary called `__var_doc__` or so. Granted, that's an inconsistent design (also for type annotations), it would be better if variables themselves could have attributes, not just the objects referenced by them. That's related to the inconsistency that functions and classes are objects and can be referenced by variables like any object, but have names by themselves. – A. Donda Mar 02 '21 at 07:41
  • @A.Donda yes, but the answer was written 8 years ago and Python has moved on a lot. Yes, today you can use annotations to provide what the OP wanted and my answer is no longer correct. I will update it a bit. – Duncan Mar 02 '21 at 08:30
  • @A.Donda I updated the answer, hope you like it better now. – Duncan Mar 02 '21 at 08:49
  • @Duncan, I actually only meant type annotations as a similar case, not as a way to implement variable docs. But I now learned about `Annotated`, thanks! Do you know whether any live or html-generating documentation systems use this feature? – A. Donda Mar 03 '21 at 04:47
  • @A.Donda Annotated is pretty new. I know that Fast API will generate OpenAPI schema from type annotations which it does using Pydantic and Pydantic does support `typing.Annotated` so I think that means you can use it to include descriptions and examples and stuff in the openapi schema and of course you can format that into documentation for an api. That's all I know of. For generic docs I found this open issue: https://github.com/agronholm/sphinx-autodoc-typehints/issues/149 – Duncan Mar 03 '21 at 10:46
  • If you aren't on Python 3.9 yet, you can use this by installing the typing_extensions package https://pypi.org/project/typing-extensions/ – Kyle Barron Mar 04 '21 at 20:34
  • I don't know of any tooling that supports using `typing.Annotated` in this way. – shadowtalker Sep 01 '21 at 00:56
  • 1
    @shadowtalker Pydantic (and therefore also FastApi) can use typing.Annotated although you have to use a `Field` instance rather than a simple docstring. I'll add something about them to the answer. – Duncan Sep 10 '21 at 09:19
  • I'm not seeing any custom strings in VS Code, I only see the type associated. Is there any way to get it to show? – KTibow Feb 19 '22 at 20:08
  • `typing.Annotated` does not appear to be supported any longer as of Python 3.7 at least, unless I am doing something wrong. However, adding a docstring directly to a variable works at least for VS Code, and works independently of any normal type annotation (does not interfere with them). – LightCC Nov 14 '22 at 22:20
  • @LightCC a lot of the newer typing/typing_extensions stuff simply won't work at all on Python 3.7; I'd suggest upgrading to a newer version of Python if you can. Python 3.7 goes end of life in 7 months (June 2023) anyway so definitely think of upgrading. – Duncan Nov 16 '22 at 12:16
  • 1
    @Duncan I'd love to, but am using Python with other software that has programming APIs that support a range of Pythons with 3.7 as the newest. One only supports 2.7 (because it supports Jython)... We can (and will eventually) update those dependent software tools, but a lot of production embedded software is dependent so it's not a simple task. – LightCC Nov 17 '22 at 22:05
97

Epydoc allows for docstrings on variables:

While the language doesn't directly provides for them, Epydoc supports variable docstrings: if a variable assignment statement is immediately followed by a bare string literal, then that assignment is treated as a docstring for that variable.

Example:

class A:
    x = 22
    """Docstring for class variable A.x"""

    def __init__(self, a):
        self.y = a
        """Docstring for instance variable A.y"""
shadowtalker
  • 12,529
  • 3
  • 53
  • 96
ford
  • 10,687
  • 3
  • 47
  • 54
40

Well, even though Python does not treat strings defined immediately after a global definition as a docstring for the variable, sphinx does and it is certainly not a bad practice to include them.

debug = False
'''Set to True to turn on debugging mode. This enables opening IPython on 
exceptions.
'''

Here is some code that will scan a module and pull out names of global variable definitions, the value and a docstring that follows.

def GetVarDocs(fname):
    '''Read the module referenced in fname (often <module>.__file__) and return a
    dict with global variables, their value and the "docstring" that follows
    the definition of the variable
    '''
    import ast,os
    fname = os.path.splitext(fname)[0]+'.py' # convert .pyc to .py
    with open(fname, 'r') as f:
        fstr = f.read()
    d = {}
    key = None
    for node in ast.walk(ast.parse(fstr)):
        if isinstance(node,ast.Assign):
            key = node.targets[0].id
            d[key] = [node.value.id,'']
            continue
        elif isinstance(node,ast.Expr) and key:
            d[key][1] = node.value.s.strip()
        key = None
    return d
bht
  • 801
  • 8
  • 18
13

Sphinx has a built-in syntax for documenting attributes (i.e. NOT the values as @duncan describes). Examples:

#: This is module attribute
x = 42

class MyClass:

    #: This is a class attribute
    y = 43

You can read more in the Sphinx docs: https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#directive-autoattribute

...or in this other question: How to document a module constant in Python?

benjaoming
  • 2,135
  • 1
  • 21
  • 29
9

Some python documentation scripts have notation that can be use in the module/classes docstring to document a var.

E.g. for spinx, you can use :var and :ivar. See this document (about half-way down).

aliteralmind
  • 19,847
  • 17
  • 77
  • 108
Gary van der Merwe
  • 9,134
  • 3
  • 49
  • 80
6

To add to to ford's answer about Epydoc, note that PyCharm will also use a string literal as the documentation for a variable in a class:

class Fields_Obj:
    DefaultValue=None
    """Get/set the default value of the data field"""
David Cater
  • 415
  • 3
  • 15
  • 1
    It's too bad the documentation can't be on the same line as the declaration. That would allow them to be rearranged easily (using a line sort command) and not lose their documentation. – Mr. Lance E Sloan Jul 29 '16 at 15:40
  • 3
    @LS: You can separate them with a semicolon. `DefaultValue = None; """Get/set the default value of the data field"""`. I don't know if Epydoc or PyCharm accept that. Epydoc also considers an assignment followed by `#:` to be a variable docstring. `x = 22 #: docstring for x` – Nick Matteo Mar 24 '17 at 15:14
  • Unfortunately, in PyCharm (2019.1) this only works if an attribute is assigned a value. If you just add type annotation without value assignment, the doc string is not picked up. – nirvana-msu May 22 '20 at 11:01
6

No, you can only do this for modules, (lambda and "normal") functions and classes, as far as I know. Other objects, even mutable ones inherit the docstrings of their class and raise AttributeError if you try to change that:

>>> a = {}
>>> a.__doc__ = "hello"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'dict' object attribute '__doc__' is read-only

(Your second example is valid Python, but the string """l""" doesn't do anything. It is generated, evaluated and discarded.)

Tim Pietzcker
  • 328,213
  • 58
  • 503
  • 561
2

Properties can have docstrings! This covers the most common use case of documenting instance variables.

class A:
    def __init__(self):
        self._x = 22

    @property
    def x(self):
        "document x"
        return self._x

    @x.setter
    def x(self, value):
        self._x = value

A.x.__doc__
Quantum7
  • 3,165
  • 3
  • 34
  • 45
  • True. But adding two methods just to have a docstring for a variable doesn't seem like a reasonable approach. – A. Donda Mar 02 '21 at 07:45
  • 2
    I agree, but if you need a solution that actually generates __doc__ rather than just generating sphinx documentation then this might be a good option. – Quantum7 Mar 02 '21 at 13:02
  • Formatting fail: I meant the dunder `__doc__` above, not the bold version. – Quantum7 Mar 03 '21 at 19:36
2

A lot of answers assume you want it for offline use and points to sphinx or Epydoc.

But if you want it for runtime use the answer is that is impossible to add an attribute to another attribute. So you can't attach a doctring to variable.

When you do:

a = True
print(a.__doc__)

You'll be getting the docstring for the bool class. In my application I need it for plug-ins. What I do is to use an associated variable/attribute.

Something like this:

a = True
_help_a = "help for a variable"

As this looks ugly what I'm actually using are syntactic macros (take a look a macropy module). The code looks like this:

with document:
    a = True
    """ help for a variable """

I explain the whole idea here

0

Yes, you can do that!

You can actually 'document' lambdas and variables in a module by attaching docstrings to them.

Not properties. Not class attributes. Variables, constants and lambdas. No Sphinx, no Epydoc. No typing.annotations. Plain old help(). Real docstrings. In the line of

VAR = value # (apply magicka to add docstring 'This is a variable')
help(VAR)   # shows 'This is a variable'

Well, sort of ...

The trick is to use decorators.

You take anything that can hold a docstring (class or function), apply decorator to it, but instead of returning modified class or wrapper class as you usually do with decorators, you can just return an object of completely different class generated on the fly with a docstring attached to it.

Something like this:

# This is ugly, yes, but it's gonna be even uglier, strap in.
@decorator_generator(lambda x: x+1)
class foo: """ docstrings """
# The decorator generator returns a decorator, which, in turn, can return
# ANYTHING AT ALL, which will be assigned to `foo`. We can use that.

The types will be very messy, but, hey, who needs them anyways.

We can also do some module class magic to reattach the docs every time a new value is assigned to module attributes, thus preserving the docs on assignment.

Consider this:

# one.py

# We import sys to use the module magicka later
import sys

def documented_named(baseclass, *init_args, **init_kwargs):
    def _decorator(decorated):
        class _documented_class(baseclass):
            def __str__(self):
                return decorated.__name__
            __doc__ = decorated.__doc__
            def __documented__(self):
                return (documented_named, baseclass, decorated)
        return _documented_class(*init_args, **init_kwargs)
    return _decorator

def documented(baseclass, *init_args, **init_kwargs):
    def _decorator(decorated):
        class _documented_class(baseclass):
            __doc__ = decorated.__doc__
            def __documented__(self):
                return (documented, baseclass, decorated)
        return _documented_class(*init_args, **init_kwargs)
    return _decorator

def documented_lambda(__lambda):
    def _decorator(decorated):
        def _lambda(*args):
            return __lambda(*args)
        _lambda.__doc__ = decorated.__doc__
        return _lambda
    return _decorator


class nopreserve: pass

def documented_ducktype(baseclass, *init_args, **init_kwargs):
    def _decorator(decorated):
        class _documented_class(baseclass):
            __doc__ = decorated.__doc__
            def __documented__(self):
                return (documented, nopreserve, decorated)
        return _documented_class(*init_args, **init_kwargs)
    return _decorator

# Module magix
_thismodule = sys.modules[__name__]
class _preserve_documented(_thismodule.__class__):
    def __setattr__(self, attr, value):
        ex = getattr(self, attr, None)
        if ex is not None and hasattr(ex, '__documented__'):
            decorator, baseclass, decorated = ex.__documented__()
            if baseclass is nopreserve:
                baseclass = value.__class__
            super().__setattr__(attr, decorator(baseclass, value)(decorated))
        else:
            super().__setattr__(attr,value)
_thismodule.__class__ = _preserve_documented

@documented(int, 100)
class VAR1: """ DOCUMENTATION FOR VAR1 """

@documented_named(float, 7.891011)
class VAR2: """ DOCUMENTATION FOR VAR2 """

@documented_lambda(lambda x: x+1)
class LAMBDA: """ LAMBDA DOCUMENTATION PROVIDED HERE """

@documented_ducktype(int, 100)
class VAR3:
    """ DOCUMENTATION FOR VAR3 
    Multiline, eh?
    """

Let's test it like this:

# two.py
import one
from one import VAR2

# inspect is here for convenience only, not needed for docs to work
import inspect

def printvar(v):
    print('str:  ', v)
    print('repr: ', repr(v))
    print('docs: ', inspect.getdoc(v))
    print('')

print('Here you go, documented variables and lambda:')
for v in [one.VAR1, one.VAR2, one.LAMBDA]:
    printvar(v)

# And then we set vars and check again
one.VAR1 = 12345
one.VAR2 = 789

print('\n\nAfter setting VAR1 and VAR2 with <module>.<varname> = foo to new values:')
for v in [one.VAR1, one.VAR2]:
    printvar(v)
print('Cool, the docs are preserved.\n\n')
print('Note that we have also preserved the types, though this is not really necessary:')
print('VAR3:')
printvar(one.VAR3)
one.VAR3 = 'VAR3 is a string now'
print('And after assignment:')
printvar(one.VAR3)

print('VAR2 imported with "from <module> import VAR2":')
printvar(VAR2)

print('However, if we set it here we will obviously loose the doc:')
VAR2 = 999
printvar(VAR2)

print('And the types are terrible:')
print('one.VAR1:  ', type(one.VAR1))
print('one.VAR2:  ', type(one.VAR2))
print('one.LAMBDA:', type(one.LAMBDA))

The output:

$ python two.py
Here you go, documented variables and lambda:
str:   100
repr:  100
docs:  DOCUMENTATION FOR VAR1 

str:   VAR2
repr:  7.891011
docs:  DOCUMENTATION FOR VAR2 

str:   <function documented_lambda.<locals>._decorator.<locals>._lambda at 0x7fa582443790>
repr:  <function documented_lambda.<locals>._decorator.<locals>._lambda at 0x7fa582443790>
docs:  LAMBDA DOCUMENTATION PROVIDED HERE 



After setting VAR1 and VAR2 with <module>.<varname> = foo to new values:
str:   12345
repr:  12345
docs:  DOCUMENTATION FOR VAR1 

str:   VAR2
repr:  789.0
docs:  DOCUMENTATION FOR VAR2 

Cool, the docs are preserved.


Note that we have also preserved the types, though this is not really necessary:
VAR3:
str:   100
repr:  100
docs:  DOCUMENTATION FOR VAR3 
Multiline, eh?

And after assignment:
str:   VAR3 is a string now
repr:  'VAR3 is a string now'
docs:  DOCUMENTATION FOR VAR3 
Multiline, eh?

VAR2 imported with "from <module> import VAR2":
str:   VAR2
repr:  7.891011
docs:  DOCUMENTATION FOR VAR2 

However, if we set it here we will obviously loose the doc:
str:   999
repr:  999
docs:  int([x]) -> integer
int(x, base=10) -> integer

Convert a number or string to an integer, or return 0 if no arguments
are given.  If x is a number, return x.__int__().  For floating point
numbers, this truncates towards zero.

If x is not a number or if base is given, then x must be a string,
bytes, or bytearray instance representing an integer literal in the
given base.  The literal can be preceded by '+' or '-' and be surrounded
by whitespace.  The base defaults to 10.  Valid bases are 0 and 2-36.
Base 0 means to interpret the base from the string as an integer literal.
>>> int('0b100', base=0)
4

And the types are terrible:
one.VAR1:   <class 'one.documented.<locals>._decorator.<locals>._documented_class'>
one.VAR2:   <class 'one.documented_named.<locals>._decorator.<locals>._documented_class'>
one.LAMBDA: <class 'function'>

And yes, you can actually import one and get the docs with help(one.VAR1) this way. And I suppose Sphinx and Epydoc can handle that pretty well if they can be forced to ignore the decorator (I did NOT test that).

Note that you can also do something similar with __metaclass__, which should look better syntax-wise, but you'll need Python 3.9 for that.

And I should get a time machine, this WAS totally possible since the decorators were introduced.