Throw TypeError when subclasses forget to call __init__

[virtuald]

• Based on Throw TypeError when subclasses forget to call __init__ pybind/pybind11#2152
• Fixes [BUG]: nanobind fails with unhelpful error message when super.__init__ isn't called by overridden constructor #1210

[virtuald]

I don't see any other test that checks for this string, but the place where the documentation discusses it is talking about a unique_ptr ownership transfer, which isn't this?

[virtuald]

Should this be a vectorcall instead?

[wjakob]

I am not opposed to improving the error message, but this seems to complex of a change to achieve that goal. It also has a performance cost even in the non-erroneous case.

[virtuald]

You're right, I was overthinking it. Now the extra overhead is just an single comparison.

[virtuald]

Never mind, my local test environment was stale when I tested it. I'll take a closer look tonight.

[virtuald]

Well, I got rid of the MRO stuff so it's a lot simpler now.

I feel like the other performance improvement would be to convert this tp_call to vectorcall, but I haven't been successful at that yet.

Edit: Ok, I got it using vectorcall when not using the limited API in Python 3.13.. and it looks like Py_tp_vectorcall isn't supported as a slot until 3.14. To fix it in 3.12/3.13 limited API I guess nanobind.nb_meta would need to add a __vectorcalloffset__ that could be set, and add Py_TPFLAGS_HAVE_VECTORCALL to it. But is that too much complexity in the name of performance?

[wjakob]

Instead of the current approach, how about a warning (PyErr_WarnEx) in the type caster when the user tries to pass an uninitialized nanobind object?

[wjakob]

Any news on this @virtuald ?

[virtuald]

I need to go back and check, but I'm pretty sure there's already a warning in the type caster when it encounters an uninitialized nanobind object. I don't think that's good enough, better to make it an exception -- and also, in my development experience I rarely encounter warnings because I forget to enable whatever setting it is that shows them, so I'm not convinced that it would be useful for beginner developers consuming a nanobind wrapped library.

Regarding your performance concerns, it seems that if we could get it to only be installed when someone is inheriting from a class (instead of every nano-bound instance) that would be a good tradeoff? Alternatively, this could be an opt-in thing that is enabled by a class_<> argument.

I'll definitely revisit this in the future, but it might be a few weeks.