Re: [Python-ideas] PEP draft: Unifying function/method classes
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 extension types? 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.
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. Jeroen.
On Sat, Mar 31, 2018 at 06:58:19PM +0200, Jeroen Demeyer wrote:
Any or all of the above.
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?
I wouldn't :-) But your PEP should cover the reason why that solution is either not possible, not satisfactory, or even more work than what you are proposing. In other words, your PEP should at least identify alternative solutions that solve the same problems, and give reasons why your solution should be preferred. [...]
Do you happen to know why the existing function classes in Python disallow subclassing? I assumed that it was for exactly this reason.
No idea. A couple of times I've tried to subclass FunctionType and that has bit me. -- Steve
On 1 April 2018 at 02:58, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
Disallowing subclasses is a simplifying assumption for builtin types, since it means they don't need to account for subclasses potentially failing to enforce class invariants. That said, allowing Cython/CFFI/etc to use the existing fast paths for native Python functions and/or builtin C functions is a reasonable justification for flipping that switch and doing the extra work needed to make it robust - it's just likely to involve adding a number of `*_CheckExact()` calls in various places. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Mar 31, 2018 at 06:58:19PM +0200, Jeroen Demeyer wrote:
Any or all of the above.
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?
I wouldn't :-) But your PEP should cover the reason why that solution is either not possible, not satisfactory, or even more work than what you are proposing. In other words, your PEP should at least identify alternative solutions that solve the same problems, and give reasons why your solution should be preferred. [...]
Do you happen to know why the existing function classes in Python disallow subclassing? I assumed that it was for exactly this reason.
No idea. A couple of times I've tried to subclass FunctionType and that has bit me. -- Steve
On 1 April 2018 at 02:58, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
Disallowing subclasses is a simplifying assumption for builtin types, since it means they don't need to account for subclasses potentially failing to enforce class invariants. That said, allowing Cython/CFFI/etc to use the existing fast paths for native Python functions and/or builtin C functions is a reasonable justification for flipping that switch and doing the extra work needed to make it robust - it's just likely to involve adding a number of `*_CheckExact()` calls in various places. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Jeroen Demeyer -
Nick Coghlan -
Steven D'Aprano