On 23 March 2018 at 06:34, Jeroen Demeyer <j.deme...@ugent.be> wrote:
> Dear python-ideas, > > I would like to draft a PEP to change the implementation of functions and > methods in CPython. The idea for this PEP come from a discussion on > https://bugs.python.org/issue30071 > > The core idea of the PEP is to reorganize classes for functions and > methods with the goal of removing the difference between functions/methods > implemented in C and functions/methods implemented in Python. > Reading the discussion on the issue, this feels more to me like PEP 357, which added the __index__ protocol such that arbitrary objects could be used for slicing. In this case, rather than the problem being operations that require a "native Python integer", the issue is with operations which currently require a native Python function object, even though most of the operations that folks implement on them can be successfully ducktyped. As Antoine notes, unifying user-defined functions and builtin functions would be fraught with backwards compatibility problems, so you probably don't want to go down that path when your goal is "Let third parties define types that are recognised by the core interpreter as being user-defined functions". If it was just about introspection, then we could define a new protocol method or attribute, update the inspect module to respect it, and call it done. However, it seems to me that the most plausible path towards granting Cython access to the optimised fast paths for native functions would be setting Py_TPFLAGS_BASETYPE on types.FunctionType, and introducing a new Py_TPFLAGS_FUNCTION_SUBCLASS flag. We can't introduce a new protocol into those paths without slowing them down, but we can replace the current PyFunction_Check() with the typical combination of a PyFunction_Check() that accepts subclasses (by looking for the new subclass flag if the exact check fails) and PyFunction_CheckExact() (which would continue to disallow native function subclasses). The PyFunction_Check() calls in the code base would then need to be reviewed to determine which of them should be replaced with PyFunction_CheckExact(). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
