on 28.02.2006 12:14 Carl Banks said the following: [snip] > >>> It's a pretty weak case to have a dedicated builtin to prevent >>> duplicates in something that changes maybe once a month, as enums tend >>> to change rather slowly. (At least, that's the way enums in other >>> languages are used, and the design you present here seems to suggest >>> you intend to use them that way as well.) And frankly, a unit test or >>> assertion could check this. >> [snip] >> >> I don't understand what you mean by 'change rather slowly'? > > Construct data structure on-the-fly from an XML file edited by multiple > people every day = changes rather quickly > > Construct data structure from a Python file that was last edited a year > and a half ago = changes rather slowly > > Typically, enums fall into the latter category. You set the enum > values, and then pretty much leave them alone, adding new values only > occasionally. (Come on, how often do the days of the week change?) > All I was saying is, changes to the enum values are infrequent enough > that having a special type just to make sure there are no duplicates is > a waste. The only justification for a built-in enum is the other stuff > you mentioned.
agreed >> One thing that is probably missing to allow this, is a enum-set-creation >> with the | operator:: >> >> Weekdays = enum('mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun') >> daysihate = Weekdays.mon | Weekdays.thu >> >> (and this discussion needs to move to python-dev ?) > > What's wrong with set((Weekdays.mon,Weekdays.thu))? Explicit is better > than implicit. agreed again. the | idea would only be for (interface) backwards compatibility. >> As for the metaclass versions: For myself, the above version feels more >> natural and straightforward (in the same way as the PEP author describes >> it), though I understand the subclassing ideas. >> >> But are there use cases for subclassing, that aren't better served with >> a new enum or something homegrown? >> Can C++/Pascal/Java enums be subclassed? > > In C++, enum is a type but not a class. Same thing with Ada. Java > didn't have enums last time I checked. Don't know about Pascal. Was more of a question for subclassing use cases in other languages. BTW Java has an enum now, which cannot be subclassed either AFAIK. And it's the same for (Delphi) Pascal. > I > didn't care too much about subclassing; I just thought different enum > constant that couldn't (or, rather, oughtn't) be compared probably > should be instances of a separate class. It doesn't matter much, > though. > Should something like this work: > > day = Weekdays.mon > isinstance(day,Weekdays) > > ? I think in the PyPI package `type(Weekdays)` is `Enum` and `type(Weekdays.mon)` is `EnumValue`, so this would not work. But membership testing `if day in Weekdays: ...` could do the same, and type-checking for enum values `isinstance(day, EnumValue)` would work (might be unpythonic though). In the cookbook recipe `enum('..')` is a function and constructs two new types on the fly, so the values of two different enums would be of a different type, but you would not be able to name it easily... cheers -- http://mail.python.org/mailman/listinfo/python-list