Ethan Furman <et...@stoneleaf.us> added the comment:
On 09/01/2018 01:21 AM, orlnub123 wrote: > On 08/31/2018 03:01 ethan.furman wrote: >> 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). Fixing bugs is often not backwards-compatible. ;) I think the number of affected people here will be low, though, because anybody who had an _convert member should have noticed that they couldn't use it. >> 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? Blocking access through the member is a low priority. For example, originally Enum members were not available from each other (so Color.Red.Blue didn't work), but that made accessing Color.Red _very_ slow. The fix for the slow made it so Color.Red.Blue now "works", although it is not recommended. Also, moving _convert to the metaclass means it is now available on Enum, Flag, and IntFlag, and every user-defined non-IntEnum class where it wasn't before. (This part will be in 3.8.) The reason _convert exists at all is to be able to convert sets of global constants into a drop-in replacement Enum, but that is only possible if the drop-in Enum is compatible with the values being replaced -- so if the values are integers (such as in the re module) then the replacement Enum must be an IntEnum; if they were strings, then the replacement Enum must be a StrEnum -- and the two cannot be mixed. >> 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? _convert is given a list of potential objects and a filter function to select the ones to keep -- it is possible, most likely due to a bug in user code, that the incoming list of objects is empty, or the filter discards all of them, leaving members empty. ---------- _______________________________________ 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
