Why pybind11 generated enum type is not PEP 435 compatible. say, it doesn't have value attribute and it's not iterable.

[frank-xlj]

EDIT(eric): Deleted template text in body. Title describes issue sufficiently.

For reference: PEP 435

EDIT 2 (eric): See #253 per Ashley's mention.

[bstaletic]

Because it predates enum.Enum by a lot.

You can use .def() on py::enum_s and give them values() and __iter__() to get what you want.

[frank-xlj]

Thanks @bstaletic for the comments. So pybind11 doesn't have the plan to make enum type PEP-435 compatible to keep backward compatibility, right?

[bstaletic]

There are no backwards compatibility concerns here. For value, it's just a simple

.def("value", [](enum_type e) { return static_cast<int>(e); })

Or you can do it from python with int(e). This is quite a small addition, so maybe we should add it.

As for __iter__, python implements it by storing a dictionary of names to enum_values inside the enum. I don't know how to implement that efficiently (without allocating), which doesn't mean it's impossible. Inefficient implementation would only hurt those who do not need iteration over an enum. Again, users can implement these on their own.

[frank-xlj]

got it. Thanks.

[YannickJadoul]

Seems solved/answered?

[EricCousineau-TRI]

Coming back to this, I would love to have this in pybind11 proper!

I have written some schema-ish stuff (like Hydra, but trying to integrate something like nptyping), and it's a bit painful to have to explicitly check if an enum is really a pybind11 enum...

Additionally, I was playing with pyrealsense2, and I wanted to print out each entry of rs2.camera_info for rs2.device. Yes, I can iterate on dir() and do some simple name/type checking, but ewwww.

I plan to implement a generic function to provide the functionality that @YannickJadoul mentioned, but I would like to eventually upstream it.

May PR sometime in the next 1-2 months.

At a minimum, it will be documentation encoding Yannick's suggested workaround.

[EricCousineau-TRI]

Ah! Looks like it's already provided via __members__, so really all we need is something like:
https://pybind11.readthedocs.io/en/stable/classes.html#enumerations-and-internal-types

def __iter__(self):
 return iter(self.__members__.values())

I think the issue that I want to check if it's a pybind11 enum still stands. I'll see if there's a way to hack in __isinstance__, but I may timebox that.

(This is assuming __members__ is efficient)

[anntzer]

FWIW I have been used the implementation at https://gist.github.com/anntzer/96f27c0b88634dbc61862d08bff46d10 to get "pythonic" enums with pybind11 (i.e., enums that actually inherit from enum.Enum). More usefully, this also allows enums to inherit from any of enum.IntEnum, enum.Flag, or enum.IntFlag, which have quite useful additional properties (e.g. nicer reprs, for flags).

It'd be nice to have something similar built into pybind11.

[EricCousineau-TRI]

Just filed #2739 which at least adds the .value attirbute.

@anntzer Thanks!
The only caveat is that it requiring enum.Enum constrains the feature to Python 3.4+ given PEP 354, and we still support Python 2.7.

I took a glance at the implementation of Enum (in 3.6.9 for my system), and it looks like supporting stuff like __iter__, __len__, and subclass checks shouldn't be too hard (also valid for Python 2.7).
https://github.com/python/cpython/blob/v3.6.9/Lib/enum.py

The main challenges will be:

(1) Ensure that py::metaclass(whatever_enum_metaclass) doesn't create segfaults, e.g. connecting to:
https://github.com/pybind/pybind11/blob/v2.6.1/include/pybind11/detail/internals.h#L308-L309
(2) Try to minimize the footprint of whichever metaclass. I'll probably start off prototyping in pure Python (using py::exec), then lower it to whatevs CPython API 🙄