[Python-Dev] constant/enum type in stdlib

Nick Coghlan ncoghlan at gmail.com
Tue Nov 23 15:16:15 CET 2010


On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> PEP 354 was rejected for two primary reasons - lack of interest and nowhere
> obvious to put it. Would it be *so bad* if an enum type lived in its own
> module? There is certainly more interest now, and if we are to use something
> like this in the standard library it *has* to be in the standard library
> (unless every module implements their own private _Constant class).
>
> Time to revisit the PEP?

If you (or anyone else) wanted to revisit the PEP, then I would advise
trawling through the standard library looking for constants that could
be sensibly converted to enum values.

A decision would also need to be made as to whether or not to subclass
int, or just provide __index__ (the former has the advantage of being
able to drop cleanly into OS level APIs that expect a numerical
constant).

Whether enums should provide arbitrary name-value mappings (ala C
enums) or were restricted to sequential indices starting from zero
would be another question best addressed by a code survey of at least
the stdlib.

And getgeneratorstate() doesn't count as a use case, since the
ordering isn't needed and using string literals instead of integers
will cover the debugging aspect :)

Cheers,
Nick.

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


More information about the Python-Dev mailing list