[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
storchaka at gmail.com
Sat Apr 13 16:30:36 CEST 2013
On 13.04.13 15:43, Eli Bendersky wrote:
> On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka <storchaka at gmail.com>wrote:
>> On 12.04.13 15:55, Eli Bendersky wrote:
>> There is some ambiguity in the term "enumeration values". On the one hand,
>> it's the singleton instances of the enumeration class (Colors.red,
>> Colors.gree, Colors.blue), and on the other hand it is their values (1, 2,
> I agree, but not sure how to resolve it. I hope it's clear enough from the
May be use "enumeration items" or "enumeration members" if instances of
the enumeration class have in mind? And left "enumeration names" and
"enumeration values" for sets of corresponding attributes (.name and
.value) of instances.
>>> But if the value *is* important, enumerations can have arbitrary values.
>> Should enumeration values be hashable?
>> At least they should be comparable ("Iteration is defined as the sorted
>> order of the item values").
> See long discussion previously in this thread.
I think this requirements (hashability and comparability (for repr() and
iteration)) should be mentioned explicitly.
>> The Python standard library has many places where named integer constants
>> used as bitmasks (i.e. os.O_CREAT | os.O_WRONLY | os.O_TRUNC, select.POLLIN
>> | select.POLLPRI, re.IGNORECASE | re.ASCII). The proposed PEP is not
>> applicable to these cases. Whether it is planned expansion of Enum or
>> additional EnumSet class to aid in these cases?
> It is applicable, in the sense that os.O_CREAT etc can be IntEnum values.
> Their bitset operation results will be simple integers. It's not planned to
> add a special enum for this - this was ruled against during the Pycon
But IntEnum is useless in such cases because a resulting mask will be an
integer an will lost its convenient printable representation. There is
almost no benefit of IntEnum before int constant.
More information about the Python-Dev