On 13.04.13 15:43, Eli Bendersky wrote:
On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka <storch...@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,
3).
I agree, but not sure how to resolve it. I hope it's clear enough from the
context.
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
discussions.
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.
_______________________________________________
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