[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[R. David Murray]

On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Sat, 23 Feb 2013 16:02:31 +0100
> > Stefan Krah <stefan at bytereef.org> wrote:
> >> eli.bendersky <python-checkins at python.org> wrote:
> >> > +Ordered comparisons between enumeration values are *not* supported.  Enums are
> >> > +not integers!
> >>
> >> Hmm. I think this limits interoperation with C libraries and prototyping
> >> C code.
> >
> > Agreed, this is a deal-breaker IMO. I'd actually argue that enums are
> > not terribly useful apart from interacting with C constants.
> 
> I've argued in the past that we should have a "Named Value" mechanism
> *before* we have a proposal to group named constants in some fashion
> (such as sequential enums, or binary flag groups). It never gained
> much traction, even though it could be more useful in many cases
> (think things like being able to tag a file descriptor with the repr
> of the object it belongs to)
> 
> After seeing this checkin, I also suggested to Eli and Barry that any
> new PEP on this topic should come with a survey of *existing*
> pseudo-enums in the standard library, and an explanation of how the
> proposal can be used to make those either easier to debug when they
> show up in error messages or otherwise make it easier to detect when
> you've made a mistake while working with them.

See also http://bugs.python.org/issue16801#msg178542 for another use
case for named values.

I've seen an awful lot of code that uses global variables or class
attributes primarily to get name validation on constant values, and I
think all of that code would be a prime candidate for using Named Values.
Some of them are also enum-like, but many of them are not.  So I'm with
Nick on this one.

--David