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.