[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Éric Araujo
Éric Araujo added the comment: Cheers! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Éric Araujo
Éric Araujo added the comment: New changeset 205dd4e14de77f9c8ed2903ddebbcf9968bbb6a9 by Éric Araujo (Miss Islington (bot)) in branch '3.6': [3.6] bpo-31567: add or fix decorator markup in docs (GH-3959) (GH-3966)

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Éric Araujo
Éric Araujo added the comment: New changeset 03b9537dc515d10528f83c920d38910b95755aff by Éric Araujo in branch 'master': bpo-31567: more decorator markup fixes in docs (GH-3959) (#3966) https://github.com/python/cpython/commit/03b9537dc515d10528f83c920d38910b95755aff

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Berker Peksag
Berker Peksag added the comment: > That said, staticmethod as a non-decorator has an important use case for > function injection in tests (using self.func in TestCase classes that work > with > a C module and an equivalent Python version). Maybe this deserves an extra

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Éric Araujo
Éric Araujo added the comment: I think existing uses of the decorator markup rely on the reader’s understanding that it’s syntactic sugar for a call and an assignment, and they don’t have decorator+function markup. The PRs for this ticket follow that. That said,

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Éric Araujo
Change by Éric Araujo : -- pull_requests: +3945 ___ Python tracker ___ ___

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Berker Peksag
Berker Peksag added the comment: Use of classmethod and staticmethod decorators as functions is still a valid use case. I think the old signatures should be kept. It should be possible to document both uses in same place: .. function:: classmethod(function)

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Roundup Robot
Change by Roundup Robot : -- pull_requests: +3944 ___ Python tracker ___

[issue31567] Inconsistent documentation around decorators

2017-10-12 Thread Éric Araujo
Éric Araujo added the comment: New changeset 0e61e67a57deb4abc677808201d7cf3c38138e02 by Éric Araujo (Daisuke Miyakawa) in branch 'master': bpo-31567: add or fix decorator markup in docs (#3959)

[issue31567] Inconsistent documentation around decorators

2017-10-11 Thread Daisuke Miyakawa
Change by Daisuke Miyakawa : -- keywords: +patch pull_requests: +3935 stage: -> patch review ___ Python tracker ___

[issue31567] Inconsistent documentation around decorators

2017-10-03 Thread Henk-Jaap Wagenaar
Change by Henk-Jaap Wagenaar : -- nosy: +Henk-Jaap Wagenaar ___ Python tracker ___

[issue31567] Inconsistent documentation around decorators

2017-10-02 Thread Éric Araujo
Éric Araujo added the comment: > What does @ mean here? If there's some meaning, the next question is, why doc > for staticmethod() > (and classmethod() in the same page) does not have it? @ means that the function is meant to be used as a decorator (the markup looks like

[issue31567] Inconsistent documentation around decorators

2017-09-24 Thread Daisuke Miyakawa
New submission from Daisuke Miyakawa: I can see inconsistency in library documentation around functions that are suitable for decorators. I'd like to clarify if it is based on my misunderstanding, or a real documentation problem. Examples: -