[issue39549] The reprlib.Repr type should permit the “fillvalue” to be set by the user
New submission from Alexander Böhn : Currently, the `reprlib.recursive_repr(…)` decorator allows a “fillvalue” parameter to be specified by the user. This is a string value that is used as a placeholder when calculating an objects’ repr – in the case of `recursive_repr(…)` the “fillvalue” defaults to '...' and may be set by the user to a string of any length. There is no such user-defined “fillvalue” on the `reprlib.Repr` type, although the '...' string is hardcoded in its implementation and used throughout. I propose that the hardcoded use of the '...' string in the code for the `reprlib.Repr` implementation should be replaced by a “fillvalue” attribute, set on the class in its `__init__(…)` method – and therefore overridable in subclasses, like the existing myriad “max*” instance attributes. PR to follow in short order. -- components: Library (Lib) messages: 361334 nosy: fish2000 priority: normal severity: normal status: open title: The reprlib.Repr type should permit the “fillvalue” to be set by the user type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39549] The reprlib.Repr type should permit the “fillvalue” to be set by the user
Change by Alexander Böhn : -- keywords: +patch pull_requests: +17716 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18343 ___ Python tracker <https://bugs.python.org/issue39549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39549] The reprlib.Repr type should permit the “fillvalue” to be set by the user
Change by Alexander Böhn : -- components: +Tests ___ Python tracker <https://bugs.python.org/issue39549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33466] Distutils does not support the compilation of Objective-C++ (“.mm”) files
New submission from Alexander Böhn : Attempting to compile an Objective-C++ source file suffixed “.mm” results in an error complaining about the file extension being unrecognized. -- components: Distutils messages: 316405 nosy: dstufft, eric.araujo, fish2000 priority: normal severity: normal status: open title: Distutils does not support the compilation of Objective-C++ (“.mm”) files type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33466] Distutils does not support the compilation of Objective-C++ (“.mm”) files
Change by Alexander Böhn : -- keywords: +patch pull_requests: +6453 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing
New submission from Alexander Böhn : When creating a new type with `typing.NewType(…)` the result is a function defined on-the-fly with no reasonable `__repr__` definition – the string representation of the type looks something like e.g. “.new_type at 0x108ae6950>” which isn’t very useful or aesthetically appealing. -- components: Extension Modules messages: 327558 nosy: fish2000 priority: normal severity: normal status: open title: String representation for types created with typing.NewType(…) are opaque and unappealing type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing
Change by Alexander Böhn : -- keywords: +patch pull_requests: +9187 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing
Change by Alexander Böhn : -- components: +Library (Lib) -Extension Modules ___ Python tracker <https://bugs.python.org/issue34963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing
Change by Alexander Böhn : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue34963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing
Change by Alexander Böhn : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue34963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing
Alexander Böhn added the comment: The proposed solution in the PR replaces the identity-function return value of `NewType(…)` with a callable class instance that adds an explicit `__repr__` function – which that function cobbles together the string representations of the supplied type and the new types’ name into a sensible and stylistically consistent “repr” output. In this capacity the `__name__` vs. `__qualname__` consideration would appear to be an implementation detail – in this case, calculating a `__qualname__` value, á la PEP-3155, doesn’t seem to be possible nor advantageous, in this specific case. On the other hand, adding `__module__` seems like it’d be a win – although I am wary about introducing a dependency on a function that starts with an underscore. How reliable and/or portable is `sys._getframe()` ? -- ___ Python tracker <https://bugs.python.org/issue34963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
