On 2018-03-31 18:09, Steven D'Aprano wrote:
> It seems like a huge amount of work
What is a huge amount of work? Writing the PEP? Implementing the PEP?
Using the PEP? Adapting existing Python code to the PEP?
> Why isn't the answer to provide a hook to support introspection?
That is a lot easier said than done. How would you do that?
The problem is that multiple classes are involved, at least
"builtin_function_or_method" and "method_descriptor". So you'll end up
with at least 3 classes (those 2 plus the existing "function")
supporting introspection. With my proposal, this is implemented only once.
And do you expect users to implement those hooks or do you expect Python
to do it? If you want to do it in Python, you'll need to add a new class
anyway. That doesn't look simpler than my PEP.
That being said, if there is a general consensus that this is the right
thing to do, I'll go for it. However, I'm afraid that people will
complain that I'm complicating functions in Python even more.
Second: while introspection was the initial motivation, it does make
sense to unify built-in functions and Python functions. For example: why
are unbound methods just functions in Python classes but not in
If you are going to do some reorganization of function classes anyway,
you might as well do it properly. I claim that functions will be
*easier* to work with in Python when my PEP is accepted, both for the
end user as well as for the implementor of custom function classes.
> Seems to me that if you want a fast, exact (no subclasses) check, you
> should use "type(obj) is Class" rather than isinstance. If the *only*
> reason to prohibit subclassing is to make isinstance a bit faster,
> I don't think that's a good enough reason.
I didn't really mean "isinstance" literally, I was mostly thinking of
the C API. I agree that it's not clear.
Do you happen to know why the existing function classes in Python
disallow subclassing? I assumed that it was for exactly this reason.