[issue25467] Put “deprecated” warnings first
Tony R.
report at bugs.python.org
Mon Oct 26 08:40:28 EDT 2015
Tony R. added the comment:
> 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”.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________
More information about the Python-bugs-list
mailing list