(original) (raw)
1) Is there limitation that EnumValues themselves must be immutable?
2)
I'm most excited by the prospect of using these Enums as function
defaults. I've not worked it through fully, but I'm
guessing the following will work?>>> class Colors(Enum):
...������� red = (256, 0, 0)
>>> def fill(color=Colors.red):
...��� pass
...
>>> from inspect import signature
>>> print(signature(fill))
(color=)
...������� red = (256, 0, 0)
>>> def fill(color=Colors.red):
...��� pass
...
>>> from inspect import signature
>>> print(signature(fill))
(color=)
3)
Enums are generally used for defining constants - Is there a case to be
made for using capitals in the 435 as PEP8 suggests, or are enums a special case?
(http://www.python.org/dev/peps/pep-0008/#constants)
4) Is there an easy way to create custom EnumValues subclasses? In particular it'd be nice to be able to change the \_\_repr\_\_ in some cases to hide the value itself, which is often not important.
Sorry if this has already been discussed elsewhere (I've only recently signed up to the dev mailinglist).
On 12 April 2013 16:23, R. David Murray <rdmurray@bitdance.com> wrote:
On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw <barry@python.org> wrote:OK.
\> Nick brought this up in private email, and my response was basically that
\> iteration order for Enums should not be guaranteed, even if that happens to
\> work in the current implementation. �The reason why it works in the current
\> implementation is purely to provide predictable reprs.
\>
\> Of course, we could sort the values for the repr and remove the sorted() call
\> in EnumMetaclass.\_\_iter\_\_() but then we would have to add it back for
\> IntEnums, since we \*do\* want to make explicit iteration order guarantees for
\> IntEnums, as they also have full rich comparisons. �I'm just not sure it's
\> worth it from an implementation point of view.
\>
\> I will update the PEP to make this more clear.
To take advantage of their incommensurability with other Enums. �It's
\> >In talking to an existing internet protocol it would be natural to use
\> >IntEnum and this issue would not arise, but I have recently worked on
\> >an application that had \*exactly\* the above sort of enumeration used
\> >internally, when it would have been totally appropriate to use Enum rather
\> >than IntEnum. �The ap has several places where an ordered comparison
\> >against the enum is used to check if a code is in the error range or not.
\>
\> Why Enums and not IntEnums? �Enums will not have ordered comparisons, but
\> IntEnums will.
not a big deal, though; I'm more concerned that the API be internally
consistent. �I presume that one could always define an Enum subclass
and provide comparison methods if desired :)
\--David
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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/pelson.pub%40gmail.com