[Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

[Jeroen Demeyer]

On 2018-09-13 02:26, Petr Viktorin wrote:
> The reference to PEP 573 is premature.

It seems to me that PEP 580 helps with the use case of PEP 573. In fact, 
it implements part of what PEP 573 proposes. So I don't see the problem 
with the reference to PEP 573. Even if the implementation of PEP 573 
changes, the problem statement will remain and that's what I'm referring to.

> If you agree I can
> summarize rationale for "parent", as much as it concerns 580.

Sure. I still think that we should refer to PEP 573, but maybe we can 
summarize it also in PEP 580.

> # Using tp_print
>
> The tp_print gimmick is my biggest worry.
> AFAIK there's no guarantee that a function pointer and Py_ssize_t are
> the same size.

I'm not actually claiming anywhere that it is the same size.

> # Descriptor behavior
>
> I'd say "SHOULD" rather than "MUST" here. The section describes how to
> implement expected/reasonable behavior, but I see no need to limit that.

There *is* actually an important reason to limit it: it allows code to 
make assumptions on what __get__ does. This enables optimizations which 
wouldn't be possible otherwise. If you cannot be sure what __get__ does, 
then you cannot optimize

obj.method(x)

to

type(obj).method(obj, x)

> "if func supports the C call protocol, then func.__set__ must not be
> implemented." -- also, __delete__ should not be implemented, right?.

Indeed. I write Python but I think C API, so for me these are both 
really tp_descr_set.

> PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall?

What's the convention for that anyway? I assumed that capital letters 
meant a "really know what you are doing" function which could segfault 
if used badly.

For me, whether something is a function or macro is just an 
implementation detail (which can change between Python versions) which 
should not affect the naming.

> # C API functions
>
> The function PyCFunction_GetFlags is, for better or worse, part of the
> stable ABI. We shouldn't just give up on it. I'm fine with documenting
> that it shouldn't be used, but for functions defined using
> PyCFunction_New etc. it should continue behaving as before.
> One solution could be to preserve the "definition time" METH_* flags in
> the 0xFFF bits of cc_flags and use the other bits for CCALL_*.

I'm fine with that if you insist. However, it would be a silly solution 
to formally satisfy the "stable ABI" requirement without actually helping.


I agree with your other points that I didn't reply to and will make some 
edits to PEP 580.


Jeroen.