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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4