[Python-Dev] PEP 590 discussion
pviktori at redhat.com
Thu Apr 25 17:11:36 EDT 2019
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
> 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
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
## 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.
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
More information about the Python-Dev