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.
_______________________________________________
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

Reply via email to