Repository navigation
Enum: modify __repr__, __str__; update docs #84247
Description
Activity
Serhiy had the idea of having Enum._convert also modify the __str__ and __repr__ of newly created enumerations to display the module name instead of the enumeration name (https://bugs.python.org/msg325007):
--> socket.AF_UNIX
<AddressFamily.AF_UNIX: 1> ==> <socket.AF_UNIX: 1>--> print(socket.AF_UNIX)
AddressFamily.AF_UNIX ==> socket.AF_UNIXThoughts?
vedgar commented
on Apr 11, 2020 vedgarmannequinMannequin_in some cases when enum instances are exposed as module globals_
Yes. And repr should be inverse of eval, but it's probably too late for that. :-/
Looks like the
remodule's flags have been updated separately in bpo-36548:>>> import re >>> re.I re.IGNORECASE >>> print(re.I) # should also be re.IGNORECASE >>> re.I|re.S|re.X re.IGNORECASE|re.DOTALL|re.VERBOSE
For stdlib Enum conversions are we happy with that? Or should __str__ just print the numeric value?
vedgar commented
on Sep 14, 2020 vedgarmannequinMannequinIf it's considered to be not too backwards-incompatible, I think it would be nice to have str different from repr. That way we can finetune what exactly we need. But we can already do almost exactly that with *int* instead of *str*, so it's not too compelling.
Much more important thing is the "repr as inverse of eval". Is there any way we can have that for our own enums (as a mixin or a decorator)?
@module_global(re) class RegexFlag(Enum): ...
It would be fantastic. :-)
"repr as inverse of eval" is nice to have, but it is not a requirement.
17 remaining items
kulikjak commented
on Jan 17, 2022 kulikjakmannequinMannequinThis also broke our Solaris build with the following error:
======================================================================
FAIL: testGetaddrinfo (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------Traceback (most recent call last): File "/..../cpython-main/Lib/test/test_socket.py", line 1523, in testGetaddrinfo self.assertEqual(repr(type), '<SocketKind.SOCK_STREAM: 1>') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: '<SocketKind.SOCK_STREAM: 2>' != '<SocketKind.SOCK_STREAM: 1>' - <SocketKind.SOCK_STREAM: 2> ? ^ + <SocketKind.SOCK_STREAM: 1> ? ^
(test.test_socket.GeneralModuleTests fails with the same error).
The issue is almost certainly that on Solaris, SOCK_STREAM is defined as 2 rather than 1; the following simple program confirms that:
#include <stdio.h> #include <sys/socket.h> void main() { printf("%d\n", SOCK_STREAM); }
I'm just not sure whether to fix this with
assertRegexor a special branch for Solaris (though I am not sure whether everybody else uses 1 or it's more varied).After merging in doc fix by kumaraditya303, I'll update tests so Solaris passes.
self.assertEqual(repr(type), '<SocketKind.SOCK_STREAM: 1>')
For this one, I suggest to replace the value with "..." doctest pattern.
vstinner wrote:
--------------> self.assertEqual(repr(type), '<SocketKind.SOCK_STREAM: 1>')
For this one, I suggest to replace the value with "..." doctest pattern.
That bit of code is from the unittest suite, not the doctest suite.
I went with:
self.assertEqual(repr(type), '<SocketKind.SOCK_STREAM: %r>' % type.value)I created python/core-workflow#424 "Should we make the Docs CI mandatory on the Python main branch?".
- added a commit that references this issue
on Nov 20, 2022
repr()andstr()#22392Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: