Home Original page

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

Antoine Pitrou solipsis at pitrou.net
Wed Jun 20 10:09:46 EDT 2018 
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.
More information about the Python-Dev mailing list