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.

classification
Title: Document PyCFunction_New and PyCFunction_NewEx functions
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: asvetlov, docs@python, gvanrossum, martin.panter, petr.viktorin, rogerhurwitz, vstinner
Priority: normal Keywords: easy

Created on 2012-12-25 11:15 by asvetlov, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
16776.txt akuchling, 2013-11-11 20:32 review
Messages (7)
msg178115 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-12-25 11:15
c-api docs has no documentation for those public API functions.
msg202651 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2013-11-11 20:32
Here's a patch that contains text for a description of these two functions.  However, I can't figure out what section they would belong in.  They don't really belong in http://docs.python.org/3.4/c-api/structures.html, which is for the C structures.

Also note that PyCFunctionObject isn't described anywhere.  Should it be?
msg202652 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2013-11-11 20:32
Mis-clicked and forgot to attach the patch.
msg232788 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2014-12-17 01:13
I’m far from an expert on the C API, but I was looking for a way to inspect a “builtin_function_or_method” a.k.a. PyCFunction_Type a.k.a. types.BuiltinMethodType, and ended up looking at the “Instance Method Objects” section. So maybe your functions should go near there, or perhaps the nearby “Function Objects” section.
msg361346 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2020-02-04 12:59
IMO, PyCFunction* should be a CPython-specific implementation detail: alternate implementations of the C-API don't need to support them, and extension authors should be fine without using them. (And if not, more efforts like PEP 590 Vectorcall should make it so.)

The functions are public in the sense that they don't have underscored names, but I wouldn't rush to make them documented.
msg361708 - (view) Author: Roger Hurwitz (rogerhurwitz) * Date: 2020-02-10 19:19
I am at PyCascades at the CPython sprint, and I will work on this issue to the best of my ability.
msg361720 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-02-10 20:37
I'm sprinting with Roger. Based on Petr's comment I am closing this issue -- if we should not draw attention to this function let's not document it.

@svetlov if you still think it should be documented, can you suggest where the documentation should go? The best place we could come up with is in the file where Andrew put it.
History
Date User Action Args
2022-04-11 14:57:39adminsetgithub: 60980
2020-02-10 20:37:46gvanrossumsetstatus: open -> closed

nosy: + gvanrossum
messages: + msg361720

resolution: not a bug
stage: resolved
2020-02-10 19:19:44rogerhurwitzsetnosy: + rogerhurwitz
messages: + msg361708
2020-02-04 12:59:12petr.viktorinsetnosy: + petr.viktorin
messages: + msg361346
2014-12-31 16:34:48akuchlingsetnosy: - akuchling
2014-12-17 01:13:20martin.pantersetnosy: + martin.panter
messages: + msg232788
2013-11-12 21:53:07vstinnersetnosy: + vstinner
2013-11-11 20:32:48akuchlingsetfiles: + 16776.txt

messages: + msg202652
2013-11-11 20:32:30akuchlingsetnosy: + akuchling
messages: + msg202651
2012-12-25 11:15:54asvetlovcreate