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-May/125967.html below:

can someone please summarize open issues?

[Python-Dev] enum discussion: can someone please summarize open issues? [Python-Dev] enum discussion: can someone please summarize open issues?Antoine Pitrou solipsis at pitrou.net
Sat May 4 16:25:18 CEST 2013
On Sat, 04 May 2013 06:37:23 -0700
Ethan Furman <ethan at stoneleaf.us> wrote:
> >>>>
> >>>> +1. An enum is basically a bidirectional mapping between some raw
> >>>> values and some "nice" instances, so it deserves a well-defined lookup
> >>>> operation in each direction.
> >>
> >> As I see it, there are 3 possible ways forward here:
> >
> > 4. Offer classmethods named Enum.by_name() and Enum.by_value().
> > Simple and explicit.
> 
> And then you can't have enum items named by_name and by_value.

You can. Normal shadowing rules apply.

By the same token, you can't have enum items named __str__ or __init__.
How is that a problem? Attribute resolution rules imply some
restrictions, which are well-known to all Python programmers.

But, really, you can decide on another name if you like: __byname__ or
_byname, etc. My point is simply that lookup doesn't *have* to invoke
operators, and explicitly named classmethods are less confusing than
repurposed operators.

Regards

Antoine.


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