[Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
Petr Viktorin
encukou at gmail.com
Thu Sep 13 14:18:11 EDT 2018
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!
More information about the Python-Dev
mailing list