@@ -154,8 +154,9 @@ documentation includes:
154154
155155 * **A docstring **
156156
157- Each docstring contains a summary line, a linebreak, the description
158- of its arguments in `Sphinx style `_, and an optional doctest.
157+ Each docstring contains a summary line, a linebreak, an optional
158+ directive (see next item), the description of its arguments in
159+ `Sphinx style `_, and an optional doctest.
159160 The docstring is extracted and reused in the :ref: `api ` section.
160161 An appropriate docstring should look like this::
161162
@@ -177,6 +178,43 @@ documentation includes:
177178
178179 """
179180
181+ * **An optional directive **
182+
183+ If you introduce a new feature, change a function/method, or remove something,
184+ it is a good practice to introduce Sphinx directives into the docstring.
185+ This gives the reader an idea what version is affected by this change.
186+
187+ The first required argument, ``VERSION ``, defines the version when this change
188+ was introduced. You can choose from:
189+
190+ * ``.. versionadded:: VERSION ``
191+
192+ Use this directive to describe a new feature.
193+
194+ * ``.. versionchanged:: VERSION ``
195+
196+ Use this directive to describe when something has changed, for example,
197+ new parameters were added, changed side effects, different return values, etc.
198+
199+ * ``.. deprecated:: VERSION ``
200+
201+ Use this directive when a feature is deprecated. Describe what should
202+ be used instead, if appropriate.
203+
204+
205+ Add such a directive *after * the summary line, if needed.
206+ An appropriate directive could look like this::
207+
208+ def to_tuple(self):
209+ """
210+ Convert the VersionInfo object to a tuple.
211+
212+ .. versionadded:: 2.10.0
213+ Renamed ``VersionInfo._astuple`` to ``VersionInfo.to_tuple`` to
214+ make this function available in the public API.
215+ [...]
216+ """
217+
180218 * **The documentation **
181219
182220 A docstring is good, but in most cases it's too dense. Describe how
0 commit comments