On 05/01/2013 02:48 PM, Eli Bendersky wrote: > > > 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. > > > > > > I'm not sure what you mean, Georg, could you clarify? > > This works: > > > >>>> from ref435 import Enum > >>>> class SocketFamily(int, Enum): > > ... AF_UNIX = 1 > > ... AF_INET = 2 > > ... > >>>> SocketFamily.AF_INET > > SocketFamily.AF_INET [value=2] > >>>> SocketFamily.AF_INET == 2 > > True > >>>> type(SocketFamily.AF_INET) > > <Enum 'SocketFamily'> > >>>> isinstance(SocketFamily.AF_INET, SocketFamily) > > True > > > > Now, with the way things are currently implemented, class IntEnum is just > > syntactic sugar for above. Guido decided against allowing any kind of > > subclassing, but as an implementation need we should keep some restricted form > > to implement IntEnum. But is IntEnum really needed if the above explicit > > multiple-inheritance of int and Enum is possible? > > Well, my point is that you currently don't have to inherit from int (or IntEnum) > to get an __int__ method on your Enum, which is what I find questionable. IMO > conversion to integers should only be defined for IntEnums. (But I haven't > followed all of the discussion and this may already have been decided.) > > > Good point. I think this may be just an artifact of the implementation - PEP 435 prohibits implicit conversion to > integers for non-IntEnum enums. Since IntEnum came into existence, there's no real need for int-opearbility of other > enums, and their values can be arbitrary anyway. > > Ethan - unless I'm missing something, __int__ should probably be removed. The reason __int__ is there is because pure Enums should be using plain ints as their value 95% or more of the time, and being able to easily convert to a real int for either database storage, wire transmission, or C functions is a Good Thing. IntEnum is for when the enum item *must* be a real, bonafide int in its own right, and the use case here is backwards compatibility with APIs that are already using real ints -- and this is really the *only* time IntEnum should be used). The downside to IntEnum is you lose all Enum type protection; so if you don't need a real int, use a fake int, er, I mean, Enum, which can easily be int'ified on demand due to its handy dandy __int__ method.
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