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

[Petr Viktorin]

On 09/13/18 02:22, Jeroen Demeyer wrote:
> 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.

I want to make it clear that PEP 580 doesn't depend on 579. Reviewers 
don't need to agree with PEP 579 to accept 580.

Here's my proposed rewording: 
https://github.com/python/peps/pull/775/files?short_path=b34f00e#diff-b34f00eeb75773c32f9b22fd7fee9771

>> # 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.

Indeed, I was thinking ahead here. Backporting this to earlier versions 
of CPython will not be completely trivial, but let's leave it to Cython.


>> # 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)

I see now. Yes, that's reasonable.


>> "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.

Well, I don't think that's a useful distinction either. This is C; 
pretty much anything can segfault when used badly.

Macros tend to be "fast": Py_TYPE just gets a member of a struct; 
Py_INCREF just increments a number. METH_NOARGS is just a number. None 
of them are very dangerous.
IMO, PyTuple_GET_ITEM is not uppercase because it's dangerous, but 
because it just reaches into memory.

> 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.

True. I'm not saying the convention is very strict or useful.


>> # 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.

Yes, it's definitely very silly. But that's not a reason to break our 
promise to the users. After all it's called "stable ABI", not "useful 
ABI" :)

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

Thank you!