[Python-ideas] Enums

[Nick Coghlan]

On Fri, Jul 29, 2011 at 6:13 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> I don't even know what these "enums" actually are any more. Part integer,
> part string, part namespace, part named constant (only not actually
> constant)... It seems to me that people are trying to dump a whole lot of
> only vaguely related functionality into a single concept. Including now a
> proposal to encourage monkey-patching modules by making it an official enum
> method.
>
> For something that is conceptually so simple, this is becoming awfully
> complicated.

Yeah, until this thread reminded me, I'd actually forgotten my own
reasons for objecting to standardising enums in the past and proposing
named values instead. I think it mostly has to do with degrees of
freedom in the design.

With named values, there are only a few elements that require explicit
design decisions:
- ints only, or arbitrary types? (my recipe is designed to work with
arbitrary types)
- effect on repr() (my recipe modifies it to include a name without
breaking any existing repr/eval round trip support)
- effect on ascii() (inherits the repr() change, since ascii() is just
repr() with a post-processing step)
- effect on str() (my recipe makes sure to leave it alone to maximise
compatibility)
- effect on serialisation (my recipe makes sure to leave it alone to
maximise compatibility)
- effect on everything else (my recipe makes sure to leave it alone to
maximise compatibility)

If any application or library wants to name values retrieved from
elsewhere (including previously pickled or serialised named values)
then it is up to them to apply the transformation at the input points
(e.g. a HTTP support library might create a mapping from server
response codes to named values, but those values would still be
serialised as ordinary integers). It's a (relatively) simple, flexible
technique to improve introspection without being overly prescriptive
about how to use it. Most design decisions are handled by the basic
rule that named values *are* functionally the same as the bare value,
they just happen to have been given a specific name that is available
for introspection (and is included in the default repr output).

Once you take the step up to the enum level and start dictating the
*grouping* behaviour along with the naming behaviour, then a whole
host of other design issues arise (in addition to the ones that arise
for general purpose named values):
- behaviour of identity comparisons
- behaviour of equivalence comparisons
- behaviour of ordering comparisons
- behaviour of isinstance checks
- API for explicit conversions to and from the underlying type
- whether or not to support implicit conversions to and from the underlying type
- how to introspect the group contents

By giving up the "this is just an ordinary value with a name" design
guideline, enums get into a lot of highly arguable territory. Guido
*could* cut through that by BDFL fiat if he wanted to, but I'm not
sure he *should* - depending on the use case, the preferred answers to
some of the design decisions mentioned above are going to legitimately
vary.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia