PEP 590: new function PyObject_VectorcallDict

[jdemeyer]

Add a new public function for doing a call with an argument vector and a dict. As @markshannon suggested, this is a cleaner API than having a single function with two meanings.

CC @encukou @scoder

[encukou]

I don't agree with the rename. The semantics are almost the same as _PyObject_FastCallDict – with one exception, the argument offset, which is a backwards compatible change.
Also, I wouldn't even call the "array+dict" calling convention vectorcall. Vectorcall is array+tuple.

Would there be any issues with keeping _PyObject_FastCallDict, just extending it to use the argument offset?
(If the function is widely useful, we'd drop the initial underscore in Python 3.9 – but that doesn't need to go in the current PEP.)

[jdemeyer]

The semantics are almost the same as _PyObject_FastCallDict

Sure, the idea is to rename

• _PyObject_FastCallKeywords -> _PyObject_Vectorcall
• _PyObject_FastCallDict -> _PyObject_VectorcallDict

(whether or not you want to keep the old names for backwards compatibility is another discussion which shouldn't influence the PEP).

Would there be any issues with keeping _PyObject_FastCallDict, just extending it to use the argument offset?

I would argue that the names PyObject_Vectorcall and PyObject_FastCallDict are too different to indicate that they are in fact closely related (imagine that you're reading the C API documentation, this would be the only public function with FastCall in its name). Also, it goes against my idea of reserving the name "fast call" for METH_FASTCALL and using "vectorcall" for the generic API.

Also, I wouldn't even call the "array+dict" calling convention vectorcall. Vectorcall is array+tuple.

It's a variation on vectorcall, I don't think it's that hard to understand. CPython has plenty of PyObject_CallXXX functions which are variations on the plain PyObject_Call.

[jdemeyer]

This is of course all bikeshedding and I'll accept any decision which is made here.

[encukou]

My preferred way to handle this would be:

• PEP 590: Mark the main API as private to allow changes in Python 3.9 #1064 gets into the PEP
• the name _PyObject_FastCallDict stays
• _PyObject_FastCallDict will allow the argument offset flag (a minor, obvious and backwards-compatible change – doesn't need a PEP)
• Do the bikeshedding for Python 3.9; rename to either PyObject_FastCallDict or PyObject_VectorcallDict

This doesn't need to be in PEP 590. It could be there, but pinning the details would probably need a longer discussion, which I want to avoid.