A.M. Kuchling added the comment: Mis-clicked and forgot to attach the patch. ---------- Added file: http://bugs.python.org/file32578/16776.txt _______________________________________ Python tracker http://bugs.python.org/issue16776 _______________________________________

Martin Panter added the comment: 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. ---------- nosy: +vadmium _______________________________________ Python tracker http://bugs.python.org/issue16776 _______________________________________

Petr Viktorin added the comment: 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. ---------- nosy: +petr.viktorin _______________________________________ Python tracker https://bugs.python.org/issue16776 _______________________________________

Guido van Rossum added the comment: 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. ---------- nosy: +gvanrossum resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker https://bugs.python.org/issue16776 _______________________________________