Author ethan.furman
Recipients barry, danishprakash, doerwalter, eli.bendersky, enedil, ethan.furman, orlnub123, serhiy.storchaka, underscore_asterisk
Date 2018-09-11.16:34:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Okay, I might be changing my mind.  In most cases I suspect the difference would be minimal, but when it isn't, it really isn't.  Take this example from a pydoc test:

  class Color(enum.Enum)
   |  Color(value, names=None, *, module=None, qualname=None, type=None, start=1)
   |  An enumeration.
   |  Method resolution order:
   |      Color
   |      enum.Enum
   |      builtins.object
   |  Data and other attributes defined here:
-  |  blue = < 3>
+  |  blue = < 3>
-  |  green = < 2>
+  |  green = < 2>
-  |  red = < 1>
+  |  red = < 1>

It feels like the important information is completely lost in the noise.

Okay, I'm rejecting the __repr__ changes.  Besides the potential verbosity, there should usually only be one of any particular Enum, __module__ and __qualname__ are both readily available when there are more than one (either on accident or by design), and users can modify their own __repr__s if they like.

I'm still thinking about the change in _convert_ to modify __str__ to use the module name instead of the class name....  Here are my questions about that:

- Modify just __str__ or __repr__ as well?
    socket.AF_UNIX instead of AddressFamily.AF_UNIX
    <socket.AddressFamily.AF_UNIX: 1> instead of <AddressFamily.AF_UNIX: 1>

- potential confusion that actual instances of Enum in the stdlib appear
  differently than "regular" Enums?  Or perhaps call out those differences
  in the documentation as examples of customization?
Date User Action Args
2018-09-11 16:34:16ethan.furmansetrecipients: + ethan.furman, barry, doerwalter, eli.bendersky, serhiy.storchaka, enedil, orlnub123, danishprakash, underscore_asterisk
2018-09-11 16:34:16ethan.furmansetmessageid: <>
2018-09-11 16:34:16ethan.furmanlinkissue34443 messages
2018-09-11 16:34:16ethan.furmancreate