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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4