[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

[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/issu

[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:

[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

[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> ___ ___ Py

[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

[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> ___ ___ Py

[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 mailin

[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:

[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:

[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