[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