This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author orlnub123
Recipients ethan.furman, orlnub123
Date 2018-09-01.23:07:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1535843258.38.0.56676864532.issue34282@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.

I think we had a misunderstanding, my proposal should be fully backwards-compatible. Maybe code can talk clearer than words? I'll attempt to turn it into a patch for 3.7 that can be backported to 3.6.

> 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.

That's honestly very interesting, thanks for the insight.

> 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.)

In my testings _convert has always been available to them as they all subclass Enum where it's defined. Was it originally meant to be defined on IntEnum?

> 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.

I understand and agree with the need for a check now however because of what I talked about above there should be a deprecation period similar to the one for renaming _convert. Would it be okay to add one?

> _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.

My confusion came from the fact that it doesn't raise any errors currently if they're empty. Are you suggesting that it should raise one?
History
Date User Action Args
2018-09-01 23:07:38orlnub123setrecipients: + orlnub123, ethan.furman
2018-09-01 23:07:38orlnub123setmessageid: <1535843258.38.0.56676864532.issue34282@psf.upfronthosting.co.za>
2018-09-01 23:07:38orlnub123linkissue34282 messages
2018-09-01 23:07:38orlnub123create