This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Tony R.
Recipients Tony R., docs@python, eric.araujo, ezio.melotti, georg.brandl
Date 2015-10-26.12:40:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> Thanks for the report and the patch.

Thank you for the review!

> I think a better way to handle this would be to add a "tag" next to the function name for both deprecations and "new in", and leave the actual deprecation/new-in notes at the bottom, something like:
> funcname(args)  [new in 3.2] [deprecated in 3.5]
>  Func description here.
>  New in 3.2: the funcname() function was added.
>  Deprecated in 3.5: funcname() has been deprecated.  Use anotherfunc() instead.

I’m not sure I understand what you mean by “tag”.

(ASIDE: I’m only marginally familiar with Sphinx, so I don’t know if “tag” has a specific meaning here.  I dabble across lots of markup-to-full-docs generation tools; Sphinx is just one that I happen to know the least.)

Are you saying that the source documentation would remain as-is, but something during the Sphinx _transformation_ would generate the new/deprecated tags?  

As long as those tags are clearly visible at-or-near the start, then I’m all for it.  If that is what you propose, then I can think of several possible ways to structure the generated HTML & CSS—and from there I would just need to dive into the Sphinx transformations and figure out where to sprinkle the “tags”.
Date User Action Args
2015-10-26 12:40:28Tony R.setrecipients: + Tony R., georg.brandl, ezio.melotti, eric.araujo, docs@python
2015-10-26 12:40:28Tony R.linkissue25467 messages
2015-10-26 12:40:28Tony R.create