Clean way to get old nanobind::enum_ in version 2.0

[keithlostracco]

Is there a relatively clean method (no fork) to get the old nb::enum_ functionality back when using nanobind 2.0? The reason I ask is that the old class enum_ worked perfectly with my Flags class and FlagBits enum class which followed a similar convention to Vulkan VkFlags and VkFlagBits. Flags is a type you can set with multiple FlagBits.

With the new method I basically need to have an int in my function signature to be able to pass something like FLAG_A | FLAG_B which isn't ideal and will force me to refactor a substantial number of function signatures.

Any suggestions would be greatly appreciated.

[skallweitNV]

I just walked into the same issue.

I made some experimental change where nb::is_arithmetic creates a IntFlag type instead of an IntEnum. This results in combined flag values to retain the IntEnum type instead of decaying to int. I also removed checking for existing values in enum_from_python.

I think IntFlag is the better match for nb::is_arithmetic enums, so maybe the implementation can be changed? The current form makes using flag enums very cumbersome.

A nice side-effect is that printing a IntFlag will show the actual flags in the value.

enum.patch

diff --git a/src/nb_enum.cpp b/src/nb_enum.cpp
index bfbbebb..8d0d412 100644
--- a/src/nb_enum.cpp
+++ b/src/nb_enum.cpp
@@ -43,7 +43,7 @@ PyObject *enum_create(enum_init_data *ed) noexcept {
                 PyUnicode_FromFormat("%U.%U", scope_qualname.ptr(), name.ptr()));
     }
 
-    const char *factory_name = is_arithmetic ? "IntEnum" : "Enum";
+    const char *factory_name = is_arithmetic ? "IntFlag" : "Enum";
 
     object enum_mod = module_::import_("enum"),
            factory = enum_mod.attr(factory_name),
@@ -55,7 +55,7 @@ PyObject *enum_create(enum_init_data *ed) noexcept {
     result.attr("__doc__") = ed->docstr ? str(ed->docstr) : none();
 
     if (is_arithmetic)
-        result.attr("__str__") = enum_mod.attr("Enum").attr("__str__");
+        result.attr("__str__") = enum_mod.attr("IntFlag").attr("__str__");
 
     result.attr("__repr__") = result.attr("__str__");
 
@@ -167,10 +167,10 @@ bool enum_from_python(const std::type_info *tp, PyObject *o, int64_t *out, uint8
                 return false;
             }
             enum_map::iterator it2 = fwd->find((int64_t) value);
-            if (it2 != fwd->end()) {
+            // if (it2 != fwd->end()) {
                 *out = (int64_t) value;
                 return true;
-            }
+            // }
         } else {
             unsigned long long value = PyLong_AsUnsignedLongLong(o);
             if (value == (unsigned long long) -1 && PyErr_Occurred()) {
@@ -178,10 +178,10 @@ bool enum_from_python(const std::type_info *tp, PyObject *o, int64_t *out, uint8
                 return false;
             }
             enum_map::iterator it2 = fwd->find((int64_t) value);
-            if (it2 != fwd->end()) {
+            // if (it2 != fwd->end()) {
                 *out = (int64_t) value;
                 return true;
-            }
+            // }
         }
 
     }

[wjakob]

Transitioning back to the old implementation of enums is definitely not planned, but perhaps the limitations you've run into can be addressed. There is a related PR #599.

[keithlostracco]

Oh that's great news. I forgot to check the PRs..

Thanks!