On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum <gu...@python.org> wrote:
> On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan <ncogh...@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.
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
