[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

2016-02-19 Thread Tony R.
Tony R. added the comment: > Part of the problem is getting the granularity right. The initial intent was > that 'version*' were annotations for the enclosing object (function, class, > method, etc.). If we want to have something more granular (parameter > added / deprecated / w

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

2016-02-19 Thread Tony R.
Tony R. added the comment: > Here are the original descriptions of the old LaTeX version. Holy crap! You all used to use LaTeX?! :D (I know--LaTeX is still going strong in academia. I just had no idea it was ever part of Python’s documentation, except as an output format.) >

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

2016-02-18 Thread Tony R.
Tony R. added the comment: > My weak opinion is that a new parameter is a new API item, not just a change > in behaviour, so should probably have “versionadded”. This was my reasoning as well. Also, when I noticed so many instances of ``.. versionchanged`` that all say “Added

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

2016-02-15 Thread Tony R.
New submission from Tony R.: In the documentation, I noticed several uses of ``.. versionchanged::`` that described things which had been added. I love Python, and its documentation, and I wanted to contribute. So, I figured a low-risk contribution would be to change ``.. versionchanged

[issue25467] Put “deprecated” warnings first

2015-10-27 Thread Tony R.
Tony R. added the comment: > On Oct 26, 2015, at 4:28 PM, Ezio Melotti <rep...@bugs.python.org> 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+.

[issue25467] Put “deprecated” warnings first

2015-10-26 Thread Tony R.
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-i

[issue25467] Put “deprecated” warnings first

2015-10-26 Thread Tony R.
Tony R. added the comment: > On Oct 26, 2015, at 1:49 PM, Ezio Melotti <rep...@bugs.python.org> 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 thinki

[issue25467] Put “deprecated” warnings first

2015-10-25 Thread Tony R.
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