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

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'm not actually claiming anywhere that it is the same size.
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.
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.

On 09/13/18 02:22, Jeroen Demeyer wrote:
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-b34f00...
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.
I see now. Yes, that's reasonable.
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.
True. I'm not saying the convention is very strict or useful.
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!

2018年9月13日(木) 18:22 Jeroen Demeyer <J.Demeyer@ugent.be>:
https://www.python.org/dev/peps/pep-0007/#naming-conventions All capital name is used for macros.

On 09/13/18 02:22, Jeroen Demeyer wrote:
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-b34f00...
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.
I see now. Yes, that's reasonable.
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.
True. I'm not saying the convention is very strict or useful.
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!

2018年9月13日(木) 18:22 Jeroen Demeyer <J.Demeyer@ugent.be>:
https://www.python.org/dev/peps/pep-0007/#naming-conventions All capital name is used for macros.
participants (3)
-
INADA Naoki
-
Jeroen Demeyer
-
Petr Viktorin