homepage

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., berker.peksag, docs@python, ezio.melotti, georg.brandl, martin.panter
Date 2016年02月18日.16:27:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1455812877.69.0.541684407424.issue26366@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 the *x* parameter" (or whatever), it strikes me that these are a *large class of changes*, which all have some kind of addition in common. If you think about it, deprecations and removals are also changes, but they are a large-enough class of changes to merit a distinct markup directive. 
So, just as this is true for "deprecated" or "deprecated-removed", I believe it is just as true for "added". Once all additions, deprecations, and removals have been marked up as such, I think find that there’s still PLENTY of annotations that remain under ``.. versionchanged``. 
Put another way: 
Since these are all different types of changes, it is most useful to the reader if the most specific *type* of change is reflected in the markup.
History
Date User Action Args
2016年02月18日 16:27:57Tony R.setrecipients: + Tony R., georg.brandl, ezio.melotti, docs@python, berker.peksag, martin.panter
2016年02月18日 16:27:57Tony R.setmessageid: <1455812877.69.0.541684407424.issue26366@psf.upfronthosting.co.za>
2016年02月18日 16:27:57Tony R.linkissue26366 messages
2016年02月18日 16:27:57Tony R.create

AltStyle によって変換されたページ (->オリジナル) /