[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Change by Serhiy Storchaka : -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Yurii Karabas <1998uri...@gmail.com> added the comment: `NewType` was converted into callable class at scope of https://bugs.python.org/issue44353 Currently `repr` of `NewType` is: ``` >>> UserId = NewType("UserId", int) __main__.UserId ``` -- nosy: +uriyyo

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Cheryl Sabella added the comment: Serhiy, It looks like Ivan approved your PR and was ready to merge it, but left it up to you for the final decision about incorporating changes from the competing PR. This is just a friendly ping in case you want to get it in for 3.8. Thanks! --

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Ivan Levkivskyi added the comment: Serhiy, thanks for benchmarks and good suggestions! > If make NewType a class, I would make the repr looking like a call This is a nice idea, it indeed looks better. We can probably also use `_type_repr()` helper for the argument (for consistency). >

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Serhiy Storchaka added the comment: PR 9951 is simpler, but it makes invoking NewType() slower, because retrieving the module from the caller frame is slow in comparison with other operations. $ ./python -m timeit -s "import typing" -- "UserId = typing.NewType('UserId', int)" PR 9808:

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Ivan Levkivskyi added the comment: OK, so now we have two "competing" PRs. I think I like Serhiy's PR a bit more, since it is simpler. I would propose to look at benchmarks and then decide. Are there any other factors I am missing for choosing one or other approach? --

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Serhiy Storchaka added the comment: PR 9951 is a simpler way. It just sets __qualname__ (and __module__ for completeness). >>> import typing >>> UserId = typing.NewType('UserId', int) >>> UserId -- ___ Python tracker

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Change by Serhiy Storchaka : -- pull_requests: +9298 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Serhiy Storchaka added the comment: There are disadvantages of using a callable class. First, creating a class is 10-100 times slower than creating a function. Second, calling it is slower than calling a function. sys._getframe() is already used in the typing module (and also in collections

[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

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Serhiy Storchaka added the comment: You can determine the module of the caller by using sys._getframe(). -- ___ Python tracker ___

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Serhiy Storchaka added the comment: For repr you need to set __qualname__, not just __name__. It may be worth to set also __module__ for pickleability and better help. -- nosy: +serhiy.storchaka ___ Python tracker

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Change by Alexander Böhn : -- nosy: +levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Change by Alexander Böhn : -- versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[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 ___ ___ Python-bugs-list mailing list

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

[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