[Python-Dev] PEP 590 discussion

[Petr Viktorin]

On 4/25/19 5:12 AM, Jeroen Demeyer wrote:
> On 2019-04-25 00:24, Petr Viktorin wrote:
>> PEP 590 defines a new simple/fast protocol for its users, and instead of
>> making existing complexity faster and easier to use, it's left to be
>> deprecated/phased out (or kept in existing classes for backwards
>> compatibility). It makes it possible for future code to be 
>> faster/simpler.
> 
> Can you elaborate on what you mean with this deprecating/phasing out?

Kept for backwards compatibility, but not actively recommended or 
optimized. Perhaps made slower if that would help performance elsewhere.


> What's your view on dealing with method classes (not necessarily right 
> now, but in the future)? Do you think that having separate method 
> classes like method-wrapper (for example [].__add__) is good or bad?

I fully agree with PEP 579's point on complexity:
> There are a huge number of classes involved to implement all variations of methods. This is not a problem by itself, but a compounding issue.

The main problem is that, currently, you sometimes need to care about 
this (due to CPython special casing its own classes, without fallback to 
some public API). Ideally, what matters is the protocols the class 
implements rather than the class itself. If that is solved, having so 
many different classes becomes curious but unimportant -- merging them 
shouldn't be a priority.

I'd concentrate on two efforts instead:

- Calling should have a fast public API. (That's this PEP.)
- Introspection should have well-defined, consistently used public API 
(but not necessarily fast).

For introspection, I think the way is implementing the necessary API 
(e.g. dunder attributes) and changing things like inspect, traceback 
generation, etc. to use them. CPython's callable classes should stay as 
internal implementation details. (Specifically: I'm against making them 
subclassable: allowing subclasses basically makes everything about the 
superclass an API.)

> Since the way how PEP 580 and PEP 590 deal with bound method classes is 
> very different, I would like to know the roadmap for this.

My thoughts are not the roadmap, of course :)


Speaking about roadmaps, I often use PEP 579 to check what I'm 
forgetting. Here are my thoughts on it:


## Naming (The word "built-in" is overused in Python)

This is a social/docs problem, and out of scope of the technical 
efforts. PEPs should always define the terms they use (even in the case 
where there is an official definition, but it doesn't match popular usage).


## Not extendable

As I mentioned above, I'm against opening the callables for subclassing. 
We should define and use protocols instead.


## cfunctions do not become methods

If we were designing Python from scratch, this should have been done 
differently.
Now this is a problem for Cython to solve. CPython should provide the 
tools to do so.


## Semantics of inspect.isfunction

I don't like inspect.isfunction, because "Is it a function?" is almost 
never what you actually want to ask. I'd like to deprecate it in favor 
of explicit functions like "Does it have source code?", "Is it 
callable?", or even "Is it exactly types.FunctionType?".
But I'm against changing its behavior -- people are expecting the 
current answer.


## C functions should have access to the function object

That's where my stake in all this is; I want to move on with PEP 573 
after 580/590 is sorted out.


## METH_FASTCALL is private and undocumented

This is the intersection of PEP 580 and 590.


## Allowing native C arguments

This would be a very experimental feature. Argument Clinic itself is not 
intended for public use, locking its "impl" functions as part of public 
API is off the table at this point.
Cython's cpdef allows this nicely, and CPython's API is full of C 
functions. That should be good enough good for now.


## Complexity

We should simpify, but I think the number of callable classes is not the 
best metric to focus on.


## PyMethodDef is too limited

This is a valid point. But the PyMethodDef array is little more than a 
shortcut to creating methods directly in a loop. The immediate 
workaround could be to create a new constructor for methods. Then we can 
look into expressing the data declaratively again.


## Slot wrappers have no custom documentation

I think this can now be done with a new custom slot wrapper class. 
Perhaps that can be added to CPython when it matures.


## Static methods and class methods should be callable

This is a valid, though minor, point. I don't event think it would be a 
PEP-level change.