[Python-Dev] PEP 580/590 discussion (original) (raw)
Jeroen Demeyer J.Demeyer at UGent.be
Thu Apr 25 10:42:45 EDT 2019
- Previous message (by thread): [Python-Dev] PEP 580/590 discussion
- Next message (by thread): [Python-Dev] PEP 580/590 discussion
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2019-04-25 00:24, Petr Viktorin wrote:
I believe we can achieve that by having PEP 590's (o+offset) point not just to function pointer, but to a {function pointer; flags} struct with flags defined for two optimizations:
What's the rationale for putting the flags in the instance? Do you expect flags to be different between one instance and another instance of the same class?
Both type flags and nargs bits are very limited resources.
Type flags are only a limited resource if you think that all flags ever added to a type must be put into tp_flags. There is nothing wrong with adding new fields tp_extraflags or tp_vectorcall_flags to a type.
What I don't like about it is that it has the extensions built-in; mandatory for all callers/callees.
I don't agree with the above sentence about PEP 580:
- callers should use APIs like PyCCall_FastCall() and shouldn't need to worry about the implementation details at all.
- callees can opt out of all the extensions by not setting any special flags and setting cr_self to a non-NULL value. When using the flags CCALL_FASTCALL | CCALL_KEYWORDS, then implementing the callee is exactly the same as PEP 590.
As in PEP 590, any class that uses this mechanism shall not be usable as a base class.
Can we please lift this restriction? There is really no reason for it. I'm not aware of any similar restriction anywhere in CPython. Note that allowing subclassing is not the same as inheriting the protocol. As a compromise, we could simply never inherit the protocol.
Jeroen.
- Previous message (by thread): [Python-Dev] PEP 580/590 discussion
- Next message (by thread): [Python-Dev] PEP 580/590 discussion
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]