orlnub123 <orlnub...@gmail.com> added the comment:
> For versions 3.6 and 3.7 the solution is to modify the shadow check at line > 236 so only DynamicClassAttributes are /not/ shadowed (meaning the _convert > method would be shadowed by an _convert member). Doing that might not be backwards-compatible. An enum with a subclassed behavior and member with the same name would shadow the behavior in favor of the member with the change. I propose adding an extra if statement under it that sets the member if it's named _convert and the _convert method on the class belongs to Enum (so it's not a behavior). > For 3.8 we can move _convert to the metaclass: I wasn't originally supportive > of this idea, but I can see it being useful for other Enum mix-ins such as > str. However, I will want to include a check that such a mix-in is there -- > probably by checking that the Enum type is a subclass of the first member's > type... something like: > > if not issubclass(cls, members[0]): > raise TypeError(...) My thought for moving _convert to the metaclass was that it didn't make much sense for it to be accessible through a member. Could you elaborate on how mix-ins come into play? > While we're making that change we can also check that members is not empty > and issue a friendlier error message. I don't quite follow, what would members be in this case? > We can also rename _convert to _convert_ in 3.8, but we'll need to have > _convert also on the metaclass and have it trigger a warning that _convert_ > is now the right way, and _convert will go away in 3.9. Sounds good. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34282> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
