[Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Wed Jun 20 10:09:46 EDT 2018
- Previous message (by thread): [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
- Next message (by thread): [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Jeroen,
On Wed, 20 Jun 2018 10:53:18 +0200 Jeroen Demeyer <J.Demeyer at UGent.be> wrote:
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.
This is very detailed and analytic. Thanks.
I dislike that the protocol is complicated, with many special cases. Ideally there would be two axes for parametrization of C calls:
- the signature of the C callee (either fast call or normal call)
- whether the callable is called as a function ("foo(...)") or as a method ("some_obj.foo(...)").
But there seems to be some complication on top of that:
PyCCall_FastCall() accepts several types for the keywords, even a dict; does it get forwarded as-is to the
cc_func
or is it first transformed?there's CCALL_OBJCLASS and CCALL_SLICE_SELF which have, well, non-obvious behaviour (especially the latter), especially as it is conditioned on the value of other fields or flags
I wonder if there's a way to push some of the specificities out of the protocol and into the C API that mediates between the protocol and actual callers?
Regards
Antoine.
- Previous message (by thread): [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
- Next message (by thread): [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]