On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord <fuzzy...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
