[Python-ideas] PEP proposal: unifying function/method classes

[Jeroen Demeyer]

Dear Nick Coghlan,

First of all, thanks for your insightful comments!

On 2018-03-24 09:09, Nick Coghlan wrote:
> 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".

First of all, my post was mainly meant to get an answer to "is this idea 
PEP-able?". I have never written a PEP and PEP 1 recommends this step. 
So it's not clear whether you want to say "that potential PEP is a bad 
idea" or just "go ahead with your PEP but be aware of backwards 
compatibility issues".

It would be good to know what your backwards compatibility worries are. 
If I have a clearer idea of what could break, it would be easier to see 
if it's possible to not break that.

Anyway, many (not all though!) backwards compatibility issues could be 
fixed by keeping the current built-in functions as a distinct type (say, 
old_style_builtin although I wouldn't use that name).

My vague plan in the PEP is to introduce a base class "basefunction" and 
have old_style_builtin and Python functions be subclasses of that. 
Cython functions would then be another subclass.

That way, we could implement "basefunction" properly and then implement 
old_style_builtin to support things like __get__ not binding as a method.

> 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.

True. In fact, I got a long way by just defining inspect.isfunction as

def isfunction(obj):
     return hasattr(type(obj), "__code__")

> 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

Why FunctionType and not BuiltinFunctionType? That's really the problem 
here: I want a function which is as fast as a built-in function but 
which behaves from a user's point of view as a Python function.

> We can't introduce a new protocol
> into those paths without slowing them down

I don't really follow you here. Are you saying that it's impossible to 
allow custom function classes that are as fast as the current builtin 
functions? Instead of adding a flag for a subclass, we could add a flag 
for "can be called as if it is a built-in function".


Jeroen.