[Python-Dev] PEP 580/590 discussion (original) (raw)

Brett Cannon brett at python.org
Thu May 9 17:09:39 EDT 2019

On Thu, May 9, 2019 at 11:31 AM Petr Viktorin <encukou at gmail.com> wrote:

PEP 590 is on its way to be accepted, with some details still to be discussed. I've rejected PEP 580 so we can focus on one place.

Here are things we discussed on GitHub but now seem to agree on: * The vectorcall function's kwname argument can be NULL. * Let's use vectorcallfunc, not vectorcall, and stop the bikeshedding. * tpvectorcalloffset can be Pyssizet (The discussions around signedness and C standards and consistency are interesting, but ultimately irrelevant here.) * PyCallMakeTpCall can be removed. * PyVectorcallFunction (for getting the vectorcallfunc of an object) can be an internal helper. External code should go through PyCallVectorcall (whatever we name it). * PYVECTORCALLARGUMENTSOFFSET is OK, bikeshedding over variants like PYVECTORCALLPREPEND won't bring much benefit. Anyone against, make your point now :)

Any reason the above are all "Vectorcall" and not "VectorCall"? You seem to potentially have that capitalization for "PyCall_MakeVectorCall" as mentioned below which seems to be asking for typos if there's going to be two ways to do it. :)

-Brett

The following have discussion PRs open: * PyCallMakeVectorCall name: https://github.com/python/peps/pull/1037 * Passing a dict to PyObjectVectorcall: https://github.com/python/peps/pull/1038 * Type of the kwnames argument (PyObject/PyTupleObject): https://github.com/python/peps/pull/1039

The remaining points are: ### Making things private For Python 3.8, the public API should be private, so the API can get some contact with the real world. I'd especially like to be able to learn from Cython's experience using it. That would mean: * PyObjectVectorcall * PyCallMakeVectorCall * PyVectorcallNARGS * METHVECTORCALL * PyTPFLAGSHAVEVECTORCALL * PyTPFLAGSMETHODDESCRIPTOR ### Can the kwnames tuple be empty? Disallowing empty tuples means it's easier for the callee to detect the case of no keyword arguments. Instead of: if (kwnames != NULL && PyTupleGETSIZE(kwnames)) you have: if (kwnames != NULL) On the other hand, the caller would now be responsible for handling the no-kwarg case specially. Jeroen points out: > The side of the caller (which should ensure not to send an empty tuple) > is CPython and there the issue of people implementing the protocol wrongly > doesn't arise. > External C code is not expected to manually use tpvectorcalloffset to make > vectorcalls: it is expected to use an API like PyCallVectorcall() and that > API will ensure to replace an empty tuple with NULL. > > I see it as an application of https://en.wikipedia.org/wiki/Robustnessprinciple > (Be conservative in what you send, be liberal in what you accept): > PyCallVectorcall should accept an empty tuple but it should not send an > empty tuple to the vectorcall function. But, if you apply the robustness principle to vectorcallfunc, it should accept empty tuples. ### METHVECTORCALL function type Jeroen suggested changing this from: PyObject *(*call) (PyObject *self, PyObject *const *args,_ _Pyssizet nargs, PyObject *kwname) to vectorcallfunc, i.e.: PyObject *(*call) (PyObject *callable, Pyssizet n, PyObject_ _*const *args, PyObject *kwnames) Mark argues that this is a major change and prevents the interpreter from sanity checking the return value of PyMethodDef defined functions. (Since the functions are defined by extension code, they need to be sanity-checked, and this will be done by PyCFunction's vectorcall adapter. Tools like Cython can bypass the check if needed.) The underlying C function should not need to know how to extract "self" from the function object, or how to handle the argument offsetting. Those should be implementation details. I see the value in having METHVECTORCALL equivalent to the existing METHFASTCALL|METHKEYWORDS. (Even though PEP 573 will need to add to the calling convention.)

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20190509/60b2e7ee/attachment.html>

More information about the Python-Dev mailing list