What counts as sufficiently int-like for a noconvert int argument?

[oremanj]

If you bind this function:

m.def("example", [](int val) { return val; }, "val"_a.noconvert());

what sort of Python objects should you be able to pass to example()?

I noticed today that nanobind and pybind11 have different opinions on this. nanobind will only accept exactly a Python int; even subclasses of int don't qualify. pybind11 accepts subclasses of int, as well as non-int objects that define __index__; but a non-int object that only defines __int__ requires a conversion.

I'm dubious about the wisdom of allowing a call to __index__ to not count as a conversion, because e.g. nanobind enums define __index__ and I'm not sure they should be accepted if someone wants an int without conversion. But subtypes of int seem pretty safe to me. I'm curious what others' opinions on this are.

[wjakob]

This is also a question of performance. Checking that the argument is exactly of type int is a pointer comparison. Checking that it is a subtype is a call into CPython to walk through the class hierarchy. AFAIK, nanobind makes similar type equality-based checks in other "primitive" casters such as bool, float, etc.

[wjakob]

FWIW I don't consider what pybind11 does any kind of reference or guideline. The type casters there grew organically driven by user requests, where sometimes it would have been better to say no to some of these requests.

[oremanj]

Sure, I only brought up pybind11 because its divergence indicates to me that the answer is not blindingly obvious; no objection if you decide it's wrong here.

[oremanj]

Python itself does a whole lot of is-this-an-int checks (which do allow subclasses), so they're optimized with a bit in the type flags:

#define PyLong_Check(op) \
        PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_LONG_SUBCLASS)
#define PyType_FastSubclass(type, flag) PyType_HasFeature((type), (flag))
static inline int
PyType_HasFeature(PyTypeObject *type, unsigned long feature)
{
    unsigned long flags;
#ifdef Py_LIMITED_API
    // PyTypeObject is opaque in the limited C API
    flags = PyType_GetFlags(type);
#else
    flags = type->tp_flags;
#endif
    return ((flags & feature) != 0);
}

Not so much worse than a pointer comparison.

[wjakob]

Note the #ifdef Py_LIMITED_API part. This generates a function call into the CPython lib in stable ABI builds, which are a priority for me.

[oremanj]

Fair enough! I don't think it's possible to avoid that when allowing subclasses on limited-API builds, which seems to settle this issue. Thanks for your consideration.