PyObject_CallOneArg?

[tjstum]

Hi there!

While studying the implementation of implicit conversions (in nb_type.cpp), I came across the new (to me!) vector call:

    PyObject *args[2] = { nullptr, src };
    result = PyObject_Vectorcall((PyObject *) dst_type->type_py, args + 1,
                                 NB_VECTORCALL_ARGUMENTS_OFFSET + 1, nullptr);

When I was reading the docs, I also noticed that there is a convenience method PyObject_CallOneArg that appears to do the same thing.

So I'm left with this feeling that the nanobind call in nb_type is intentionally using PyObject_VectorCall instead of PyObject_CallOneArg but don't see why.
I did some more digging, and I found a commit (a6739ba) that changed from PyObject_CallOneArg to NB_VECTORCALL. That makes sense since 3.8 didn't have PyObject_CallOneArg. But Python also didn't have PyObject_VectorCall until 3.9 (looks like NB_VECTORCALL would also use the provisional version). And now, the nb_type.cpp code above is in a snippet that only runs on 3.9+ (after the change to support the limited API).

So I'm wondering if there's any current reason to use PyObject_VectorCall and construct the array directly, instead of using PyObject_CallOneArg. I'm certainly not advocating for one or the other! I'm just looking to broaden my understanding.

Thanks!

[wjakob]

Hi @tjstum. The code that you see right now is the result of quite a bit of evolution, and initially PyObject_CallOneArg was not used because it's unavailable on Python 3.8 (before the ifdef you mentioned was added). Looking at the implementation of PyObject_CallOneArg in CPython, I don't think there is a performance advantage over just directly using PyObject_VectorCall. This explains why it was not changed at some point.

[tjstum]

Cool, thanks for the explanation!