On 06/20/18 01:53, Jeroen Demeyer wrote:
Hello,
Let me present PEP 579 and PEP 580.
PEP 579 is an informational meta-PEP, listing some of the issues with
functions/methods implemented in C. The idea is to create several PEPs
each fix some part of the issues mentioned in PEP 579.
PEP 580 is a standards track PEP to introduce a new "C call" protocol,
which is an important part of PEP 579. In the reference implementation
(which is work in progress), this protocol will be used by built-in
functions and methods. However, it should be used by more classes in the
future.
You find the texts at
https://www.python.org/dev/peps/pep-0579
https://www.python.org/dev/peps/pep-0580
Hi!
I finally had time to read the PEPs carefully.
Overall, great work! PEP 580 does look complicated, but it's well
thought out and addresses real problems.
I think the main advantage over the competing PEP 576 is that it's a
better foundation for solving Cython (and other C-API users) and my PEP
573 (module state access from methods).
With that, I do have some comments.
The reference to PEP 573 is premature. If PEP 580 is implemented then
PEP 573 will build on top, and I don't plan to update PEP 573 before
that. So, I think 580 should be independent. If you agree I can
summarize rationale for "parent", as much as it concerns 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. That makes the backwards-compatibility typedef in the
implementation is quite worrying:
typedef Py_ssize_t printfunc
I can see the benefit for backporting to earlier Python versions, and
maybe that outweighs worries about exotic architectures, but the PEP
should at least have more words on why this is not a problem.
# The C Call protocol
I really like the fact that, in the reference implementation, the flags
are arranged in a way that allows a switch statement to select what to
call. That should be noted, if only to explain why there's no guarantee
of compatibility between Python versions.
# 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.
"if func supports the C call protocol, then func.__set__ must not be
implemented." -- also, __delete__ should not be implemented, right?.
# Generic API functions
I'm a bit worried about PyCCall_FASTCALL's "kwds" argument accepting a
dict, which is mutable. I wouldn't mind dropping that capability, but if
it stays, we need to require that the callable promises to not modify it.
PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall?
# 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_*.
# Stable ABI
The section should repeat that PyCFunction_ClsNew is added to the stable
ABI (but nothing else).
_______________________________________________
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
