Add __int__ dunder to enums if the underlying type is_integral

[AaronSartin]

int(my_enum) worked in pybind but doesn't work in nanobind.

[hpkfft]

It doesn't seem to work in Python either:

>>> from enum import Enum
>>> class Color(Enum):
...   RED = 1
...   GREEN = 2
... 
>>> x = Color.RED
>>> int(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'Color'

[AaronSartin]

You're missing Color(int, Enum) or Color(enum.IntEnum). To implement this change properly we'd have to update the type stubs as well.

[hpkfft]

Can you share a full example, including your C++ code?

[AaronSartin]

Apologies for not giving an immediately compilable example; on mobile at the moment.

enum class Color
{
    RED,
    BLUE,
    GREEN
};

nb::enum_<Color>(m, "Color")
    .value("RED", Color::RED)
    .value("BLUE", Color::BLUE)
    .value("GREEN", Color::GREEN);

In python, with the above bindings, you can do Color.RED.value to get 0 and Color.BLUE.value to get 1. In pybind you could similarly do int(Color.BLUE) to get 1; the int(Color.BLUE) call errors in nanobind. The int call in python just calls the __int__ dunder; it's appropriate to have it defined for an enum with an is_integral type under the hood; that's almost all enums I've personally encountered in C++.

If this update is done we would want to update the type stubs to have the class be Color(int, Enum) instead of just Color(Enum).

[hpkfft]

Does nanobind behave as you would want if you specify nb::is_arithmetic()?
See: https://nanobind.readthedocs.io/en/latest/classes.html#enumerations-and-internal-types

[AaronSartin]

Ah, it should. I missed that in the docs. Thanks!

I would argue that it should be the default behavior based on std::underlying_type but this definitely solves my use case.