On Tue, Oct 6, 2020 at 1:16 AM Stefan Behnel <stefan_ml@behnel.de> wrote:
Stefan Behnel schrieb am 29.09.20 um 11:48:
One thing that I'm missing from the PEP is the C side of things, though. How are C extension types going to implement this?
Will there be two new slot methods for them? Something like (but better named than) "mp_subscript_kw()" and "mp_ass_subscript_kw()"?
Would the extension types signal their availability with a new "TP_*" class feature flag?
Are the slot methods going to use the vectorcall calling convention, i.e. pass the keyword names as a tuple, or should they accept (and thus, require the overhead of) a Python dict as argument?
This design must clearly be part of the PEP. What's the current status of the discussion there?
So, should I conclude from the silence that there has not been any discussion of this so far?
That's unfortunately right. I think the main reason is that the PEP authors are not very familiar with the C API. You ask some good questions about the style of the API. Right now the only bit of C API in the PEP is the proposal to add `PyObject_GetItemWithKeywords()` and friends, which do take a dict as argument. We could define new slots that have the same signature, or we could add a new flag to the type object's tp_flags field stating that the existing slots take a dict as argument. I'm not sure that we need a vector style API here -- I have a feeling that this isn't going to be performance critical. (Certainly not for most people, and not for the PEP authors' use cases.) If you really want to help, maybe you can do a little prototype coding and propose a specific API? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>