A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2013-February/124309.html below:

[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, asBarry Warsaw barry at python.org
Mon Feb 25 19:05:02 CET 2013
On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:

>>      >>> Colors = make('Colors', 'red green blue'.split())
>>      >>> Animals = make('Animals', 'ant bee cat'.split())
>>      >>> Colors.green == Animals.bee
>
>But this I don't, and in both mine, Ted's, and Alex's versions enums from
>different groups do not compare equal, regardless of the underlying value.
>Of course, this does have the potential problem of `green == 1 == bee` but
>not `green == bee` which would be a problem with set and dicts -- but I'm the
>only one who has brought up that issue.

Right, but my point is that if isinstance(Colors.green, int) then a reasonable
interpretation is that enum values will compare equal against other ints.  It
seems weird to me that enum values *are* ints but aren't substitutable with
ints (e.g. comparable against other ints including other subclasses of ints).

>However, as I replied to Skip, I think a stdlib solution should meet many
>needs, and sometimes (often, for some people ;) those needs will be better
>served by an int-based or str-based enum.

Maybe.  I don't think a stdlib solution has to meet *all* needs.  I think
named values plus int-interoperable enums will solve almost all use cases.

-Barry
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4