[Python-Dev] constant/enum type in stdlib (original) (raw)

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