Am 01.05.2013 20:04, schrieb Eli Bendersky: > Actually, in flufl.enum, IntEnum had to define a magic __value_factory__ > attribute, but in the current ref435 implementation this isn't needed, so > IntEnum is just: > > class IntEnum(int, Enum): > ''' > Class where every instance is a subclass of int. > ''' > > So why don't we just drop IntEnum from the API and tell users they should do the > above explicitly, i.e.: > > class SocketFamily(int, Enum): > AF_UNIX = 1 > AF_INET = 2 > > As opposed to having an IntEnum explicitly, this just saves 2 characters > (comma+space), but is more explicit (zen!) and helps us avoid the special-casing > the subclass restriction implementation. Wait a moment... it might not be immediately useful for IntEnums (however, that's because base Enum currently defines __int__ which I find questionable), but with current ref435 you *can* create your own enum base classes with your own methods, and derive concrete enums from that. It also lets you have a base class for enums and use it in isinstance(). If you forbid subclassing completely that will be impossible. Georg
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