@FelixAlipaz suggested to add, either as feature in the code or as example in the documentation, a way to restrict which value the enum could be set to based on its current value, ie. to enforce a limited set of allowed state transitions in cases where the enum is used to track a state.
Arguments against implementing this as a feature in the code are:
- It is a bit out of scope, this is meant to tackle the problem of a multiprocessing safe enum
- The problem also applies to any normal enum, so probably would be better solved there or in an layer between, e.g. build a
StateIntEnum that handles the transition logic and allow this to use that one as an alternative to the regular IntEnum.
A basic example could be provided in the documentation though, however to make this nice and compact, a change in the code would still make sense:
Add a method that implements the "any to value" conversion part of the set() method and and have the latter use that, so that an overridden example set() method could reuse that new method to first convert the input to a value that then is checked against the allowed transitions.
@FelixAlipaz suggested to add, either as feature in the code or as example in the documentation, a way to restrict which value the enum could be set to based on its current value, ie. to enforce a limited set of allowed state transitions in cases where the enum is used to track a state.
Arguments against implementing this as a feature in the code are:
StateIntEnumthat handles the transition logic and allow this to use that one as an alternative to the regularIntEnum.A basic example could be provided in the documentation though, however to make this nice and compact, a change in the code would still make sense:
Add a method that implements the "any to value" conversion part of the
set()method and and have the latter use that, so that an overridden exampleset()method could reuse that new method to first convert the input to a value that then is checked against the allowed transitions.