Ethan Furman <[email protected]> added the comment:
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 = <test.test_enum.TestStdLib.Color.blue: 3>
+ | blue = <Color.blue: 3>
|
- | green = <test.test_enum.TestStdLib.Color.green: 2>
+ | green = <Color.green: 2>
|
- | red = <test.test_enum.TestStdLib.Color.red: 1>
+ | red = <Color.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?
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue34443>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
