On 2018-06-20 16:09, Antoine Pitrou wrote:
But there seems to be some complication on top of that:
- PyCCall_FastCall() accepts several types for the keywords, even a
dict;
That is actually a *simplification* instead of a *complication*.
Currently, there is a huge amount of code duplication between
_PyMethodDef_RawFastCallKeywords and _PyMethodDef_RawFastCallDict.
Folding both of these in one function actually makes things simpler.
does it get forwarded as-is to the `cc_func` or is it first
transformed?
Transformed (obviously, otherwise it would be a huge backwards
incompatibility problem).
- 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
It's actually quite obvious when you think of it: both are needed to
support existing use cases. Perhaps it's just not explained well enough
in the PEP.
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?
Sorry, I have no idea what you mean here. Actually, those flags are
handled by the C API. The actual C functions don't need to care about
those flags.
_______________________________________________
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
