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

Michael Foord fuzzyman at voidspace.org.uk
Tue Nov 23 15:24:18 CET 2010

On 23/11/2010 14:16, Nick Coghlan wrote:

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 :) Well, for backwards compatibility reasons the new constants would have to behave like the old ones (including having the same underlying value and comparing equal to it).

In many cases it is likely that subclassing int is a better way of achieving that. Actually looking through the standard library to evaluate it is the only way of confirming that.

Another API, that reduces the duplication of creating the enum and setting the names, could be something like:

 make_enums("Names", "NAME_ONE NAME_TWO NAME_THREE", base_type=int,

module=name)

Using name we can set the module globals in the call to make_enums.

All the best,

Michael

Cheers, Nick.

-- http://www.voidspace.org.uk/

More information about the Python-Dev mailing list