[Python-Dev] enum discussion: can someone please summarize open issues?
eliben at gmail.com
Mon Apr 29 15:51:59 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.
> > slight concern I have with making the duck typed exclusion only
> > (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
> 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.
I don't feel strongly about allowing ()-lookup in addition to -lookup,
but in this paragraph the issue of multiple definitions has sneaked in :-)
flufl.enum disallows this:
red = 1
blue = 2
green = 1 # oops!
Has it been decided that this is now allowed? If this is indeed the case,
then Color(1) is a problem. The options are:
A. Return either Color.red or Color.green
B. Throwing an error
Do we have a decision on this? Personally I think the latter is better; the
former is error prone and doesn't seem to be useful too often.
Eli [trying to tie loose ends for updating the PEP].
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev