Vedran Čačić added the comment:
It's true, but it seems that with Enums, we're trying to retrain people to use
identity testing (see https://docs.python.org/3/library/enum.html#comparisons).
It would be unfortunate if we had to reuntrain them. :-/
Ethan's proposal (of caching weakrefs) is fine, if he manages to do it
correctly (I didn't). It's much more complicated than it seems at first, since
it has to work during the class definition itself, too.
Ok, second problem I encountered: zeros. Imagine
class MyFlags(enum.Flags):
NONE = 0
FIRST = 1 << 0
SECOND = 1 << 1
What is MyFlags.FIRST & MyFlags.SECOND? 0 or MyFlags.NONE? Or even False? :-) I
would almost be for the third option, if not for the fact that & is used not
only for "membership" testing, but also (with ~) for clearing flags. Imitating
Go, we might want to introduce another operator, &~, for clearing flags, but
that would probably be a too great disruption.
MyFlags.NONE seems cool, but then we have an enum member that is false, another
thing we have tried to avoid with current Enum design (that's why functional
API starts values at 1, for example). And what about the case when MyFlags
doesn't define NONE, only FIRST and SECOND?
If you opt for 0, you open another can of worms: first, return type depends on
argument values, and Guido hates that. :-) Also, that 0 is still somehow tied
to MyFlags: it would be a type error to write (MyFlags.FIRST & MyFlags.SECOND)
| AnotherFlags.SOMETHING, right?
Maybe the correct solution is to _always_ have a special value in every Flags
class for such cases, but then what is it's ~__NONE__? :-) Fortunately, once
you add __NONE__ and __ALL__, you get a Boolean closure, and you can
meaningfully define &, |, ^ and ~ in a type-safe way. But that's probably
overkill.
And so on... there are a lot of problems, and I've been through them. I'd like
you to succeed where I didn't, but I have a bad feeling.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23591>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
