[issue25467] Put “deprecated” warnings first

Change by Georg Brandl : -- nosy: -georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25467] Put “deprecated” warnings first

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25467] Put “deprecated” warnings first

Tony R. added the comment: > On Oct 26, 2015, at 4:28 PM, Ezio Melotti wrote: > > This is true, but on the other hand you might want to see the [new in 3.4] > while looking at 3.6 docs and working on a program that must support Python > 3.3+. Anyway we can discuss

[issue25467] Put “deprecated” warnings first

Ezio Melotti added the comment: I would rather avoid a JS-based solution. It should be possible to create a mixin that adds the checks for deprecated/versionadded directives among the children of the node, and then define new directives for functions/methods/classes that inherit from the

[issue25467] Put “deprecated” warnings first

Ezio Melotti added the comment: Thanks for the report and the patch. 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

[issue25467] Put “deprecated” warnings first

Ezio Melotti added the comment: > I don't want to be distracted by "new in 3.1" tags when reading > the 3.6 documentation. This is true, but on the other hand you might want to see the [new in 3.4] while looking at 3.6 docs and working on a program that must support Python 3.3+. Anyway we

[issue25467] Put “deprecated” warnings first

Ezio Melotti added the comment: > I’m not sure I understand what you mean by “tag”. >> funcname(args) [new in 3.2] [deprecated in 3.5] >> Func description here. I mean some kind of tag/label next to the name of the function in the documentation (red/orange for deprecations, green for

[issue25467] Put “deprecated” warnings first

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

[issue25467] Put “deprecated” warnings first

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___

[issue25467] Put “deprecated” warnings first

Tony R. added the comment: > On Oct 26, 2015, at 1:49 PM, Ezio Melotti wrote: > > Not sure if there's a clever way to do it though (maybe a CSS class can be > added to the directives and the labels can be added with CSS :after). I was thinking something along these

[issue25467] Put “deprecated” warnings first

R. David Murray added the comment: I think Ezio's idea is great. I would not want to see the notices at the top, but a label would make things clear (and the label could be hyperlinked to the note, since sometimes they are a bit of a distance away). Someone has to figure out the Sphinx

[issue25467] Put “deprecated” warnings first

Ezio Melotti added the comment: > Note that the 'new' label should only appear for stuff that is new > in that release. This is not a problem if it says [new in x.y] explicitly. This way for each version-added/version-changed/deprecated/deprecated-remove directive we will also have a label.

[issue25467] Put “deprecated” warnings first

R. David Murray added the comment: Insert "in my opinion" into that sentence. I don't want to be distracted by "new in 3.1" tags when reading the 3.6 documentation. It isn't new from my POV :) -- ___ Python tracker

[issue25467] Put “deprecated” warnings first

New submission from Tony R.: Python has wonderful, detailed documentation. I love it! Unfortunately, I have often found myself reading the otherwise-excellent documentation on a class/function/whatever, only to find out at the END of my reading that it is deprecated. This is frustrating,