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

Reply via email to