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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
