On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka <storch...@gmail.com>wrote:
> On 12.04.13 15:55, Eli Bendersky wrote:
>
>> The enumeration value names are available through the class members::
>>
>> >>> for member in Colors.__members__:
>> ... print(member)
>> red
>> green
>> blue
>>
>
> This is unnecessary because enumerations are iterable. Colors.__members__
> is equal to [v.name for v in Colors] and the latter looks more
> preferable, because it does not use the magic method.
>
>
Right. Fixed (removed this part because it's redundant), thanks.
>
> The str and repr of the enumeration class also provides useful
>> information::
>>
>> >>> print(Colors)
>> <Colors {red: 1, green: 2, blue: 3}>
>> >>> print(repr(Colors))
>> <Colors {red: 1, green: 2, blue: 3}>
>>
>
> Does the enumeration's repr() use str() or repr() for the enumeration
> values? And same question for the enumeration's str().
>
>
str
>
> To programmatically access enumeration values, use ``getattr``::
>>
>> >>> getattr(Colors, 'red')
>> <EnumValue: Colors.red [value=1]>
>>
>
> How to get the enumeration value by its value?
>
>
I've updated the PEP since then. It also shows how to use __getitem__
syntax to access by value.
>
> Ordered comparisons between enumeration values are *not* supported. Enums
>> are
>> not integers (but see `IntEnum`_ below)::
>>
>
> It's unexpected if values of the enumeration values have the natural
> order. And values of the enumeration values *should be* comparable
> ("Iteration is defined as the sorted order of the item values").
>
> Enumeration values
>> ------------------
>>
>
> 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.
>
> 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.
>
> ``IntEnum`` values behave like integers in other ways you'd expect::
>>
>> >>> int(Shape.circle)
>> 1
>> >>> ['a', 'b', 'c'][Shape.circle]
>> 'b'
>> >>> [i for i in range(Shape.square)]
>> [0, 1]
>>
>
> What is ``isinstance(Shape.circle, int)``? Does PyLong_Check() return true
> for ``IntEnum`` values?
>
>
Yes. IntEnumValue (the value class underlying IntEnum) subclasses int.
>
> Enumerations created with the class syntax can also be pickled and
>> unpickled::
>>
>
> This does not apply to marshalling, I suppose? Perhaps this is worth to
> mention explicitly. There may be some errors of incompatibility.
No special provision has been made for marshalling.
The ``Enum`` class is callable, providing the following convenience API::
>
> >>> Animals = Enum('Animals', 'ant bee cat dog')
> >>> Animals
> <Animals {ant: 1, bee: 2, cat: 3, dog: 4}>
> >>> Animals.ant
> <EnumValue: Animals.ant [value=1]>
> >>> Animals.ant.value
> 1
>
> The semantics of this API resemble ``namedtuple``. The first argument of
> the call to ``Enum`` is the name of the enumeration. The second argument
> is
> a source of enumeration value names. It can be a whitespace-separated
> string
> of names, a sequence of names or a sequence of 2-tuples with key/value
> pairs.
>
Why the enumeration starts from 1? It is not consistent with namedtuple, in
> which indices are zero-based, and I believe that in most practical cases
> the enumeration integer values are zero-based.
I don't know if there was a special reason for this. Perhaps backwards
compatibility with existing flufl.enum APIs. Barry may know more about this.
> Use-cases in the standard library
> =================================
>
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.
Eli
_______________________________________________
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
