[Python-Dev] enum discussion: can someone please summarize open issues?

Eli Bendersky eliben at gmail.com
Mon Apr 29 14:41:32 CEST 2013

On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum <guido at python.org> wrote:

> On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Functions are descriptors, so this rule already covers ordinary methods.
> The
> > slight concern I have with making the duck typed exclusion only
> descriptors
> > (rather than descriptors and callables) is that it means things like
> > functools.partial objects will be treated as enum values rather than as
> > static methods. OTOH, explicitly wrapping such callables in staticmethod
> > should still work, so the simpler rule is probably better.
> I think the practice of using callables (other than possibly decorated
> functions) as global variables is confusing at best, even in a
> non-enum class, since few people will be able to predict whether they
> will get the instance passed or not. So I think the rule looking only
> for descriptors is superior.
> There has been a whole lot more discussion in this thread. I am now
> asking everyone to stop bikeshedding, even if you think *your* point
> isn't bikeshedding -- the cacophony makes it impossible to hear
> anyone.
> There are a few more issues on which I'd like to pronounce.
> 1. The order in which iter(Color) should produce the items. The
> argument has been made that definition order is the only order that is
> not easily reconstructed, and I agree. So let's use definition order,
> even if that means it can't be implemented in Python 2.
> 2. Whether Color(x) should be allowed, and what it should mean. Taking
> the example of bool, it should return an existing enum if the argument
> is either a Color or one of the values used for Color items (choosing
> one somehow if there are multiple with the same value -- it doesn't
> matter which one), and raise an exception if the argument is neither.
> E.g.:
>   class Color(Enum):
>      red = 1
>      white = 2
>      blue = 3
> x = Color.red
> assert Color(x) is Color.red
> assert Color(1) is Color.red
> Color(42)  # raises
> (2a. We could also allow Color('red') is Color.red, but that could be
> confusing, and we can already do that with getattr(Color, 'red'), and
> bool('False') doesn't return False anyway, so let's not do that.)
> (2b. Let's not hypergeneralize and try to make bool and enums
> completely alike. I see no advantage to adding bool.True and
> bool.False, nor in making enums "final" classes, or giving a meaning
> to iter(bool). Type bool is its own thing, but that doesn't mean enums
> can't emulate aspects of it.)
> Together with my pronouncements earlier in this thread I am hoping
> that Eli and Barry will update the PEP and implementation (let's give
> them a week) and everyone else will quiet down. I realize we're
> deviating further from flufl.enum than our initial hope, but I think
> the outcome is better.

Sounds like a plan. Thanks for trying to converge things, Guido. Personally
I don't have strong opinions about the changes inflicted by recent threads,
but I may stumble into something as I dive deeper. I was away for a couple
of days and a lot has changed - I'll need some time to catch up, but
updating the PEP by the end of the week seems reasonable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130429/39051317/attachment.html>

More information about the Python-Dev mailing list