Repository navigation
#[pyclass] on enums MVP #2013
Description
After #2002 it's legal to use #[pyclass] on enums that have only unit variants.
However, there's a few pieces which need finishing (at a minimum) before releasing this change in 0.16:
- The generated class most likely wants a
__richcmp__implementation so that comparisons work as expected -
__repr__implementation - The generated class may want a metaclass to prevent subclassing
- Docs in the guide
- It would be nice to support custom discriminants a-la Support exporting Rust enums to Python (old school / without data) #834
- CHANGELOG entry
Activity
davidhewitt commentedon Nov 21, 2021
(Also, if anyone has strong opinion that this to be a separate
#[pyenum]macro instead of part of#[pyclass], it would be better to split it out before 0.16. Personally I quite like having just the one#[pyclass]macro.)jovenlin0527 commentedon Nov 21, 2021
How about we introduce a new trait in
src/class/impl_.rsthat allows us to add default implementations for magic methods? This may be useful for other situations.Related to #906.
It's not clear what's the expected behavior. Python's
IntEnumsubclasses fromint, but that's not currently supported in PyO3, and it makes the enum immutable.davidhewitt commentedon Nov 21, 2021
Agreed for sure. See also #1375 / #1376 which spoke about making "dataclass"-style
#[pyclass]with hash, eq etc.Yes I think we can live without this for now as it's an ergonomics improvement in my eyes rather than core functionality.
For C-style enums in #834, I would suggest that if comparisons against integers work as expected then that's probably a great starting point. We will probably want to get feedback from users as to how they want to interact with these things, and shouldn't be afraid of making changes after 0.16 once we do get some feedback.
davidhewitt commentedon Nov 21, 2021
We could also solve the subclassing-from-int issue if you think that's necessary. I don't think we're that far out from achieving it.
jovenlin0527 commentedon Nov 21, 2021
I don't have a strong opinion on how to implement that. I suggested subclassing
intbecause that's whatIntEnumdoes and I assumed that's what the user would expect, but I never usedIntEnumso I'm not really sure. I think it's fine to implement that in a simple way (i.e.__int__and__eq__) and see how users will think.jovenlin0527 commentedon Nov 24, 2021
On C-style enums. Rust generates a default discriminant for every variant that doesn't have a discriminant. But also Rust supports any expression (e.g.2 + 2) as custom discriminants. That means if the user used such expression in their custom discriminants, then we cannot find the default discriminant for other variants without evaluating those expressions. I think we either ban any expressions that are not literals, or we don't support default discriminant. Or both.By the way, do we treat all enums without data as C-style enums, even if there's no custom discriminant in the enum?
birkenfeld commentedon Nov 24, 2021
Why do you need to calculate the discriminants? Can't you just always use
Enum::Var as uXXin the generated code?jovenlin0527 commentedon Nov 24, 2021
I didn't know you can cast them to
uXX😅. Yeah let's cast tousize.