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!
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
