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 ncoghlan
Recipients ncoghlan, serhiy.storchaka, vstinner
Date 2016-11-30.12:27:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1480508833.61.0.377617270605.issue28838@psf.upfronthosting.co.za>
In-reply-to
Content
Independently of anything else, any changes made to the parameter names in the implementation should be reflected in the API docs: https://docs.python.org/3/c-api/object.html#c.PyCallable_Check

A style guide addition to PEP 7 would also be useful as a record of the preferred naming scheme.

That said, one of the problems you're up against inside the C code base is that we really do have some code evaluation APIs that only work with true Python functions, while a abstract APIs handle arbitrary callables. Reserving "func" for the former cases helps make it clear which is which.

By contrast, end user code (and even the standard library) can usually get away with saying "func" even when they mean "arbitrary callable" without causing confusion, as there's only the one Python-level call syntax.

So perhaps one way to start here would be to propose an addition to https://www.python.org/dev/peps/pep-0007/#naming-conventions specifically for dealing with callable parameters in APIs that covers parameters that are:

- arbitrary callables
- specifically a synchronous Python function
- method names (whether as const char *, PyObject *, or _Py_Identifier)
History
Date User Action Args
2016-11-30 12:27:13ncoghlansetrecipients: + ncoghlan, vstinner, serhiy.storchaka
2016-11-30 12:27:13ncoghlansetmessageid: <1480508833.61.0.377617270605.issue28838@psf.upfronthosting.co.za>
2016-11-30 12:27:13ncoghlanlinkissue28838 messages
2016-11-30 12:27:13ncoghlancreate