-
-
Notifications
You must be signed in to change notification settings - Fork 31.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add _repr
to named tuples
#129343
Comments
There is a number of workarounds: class Import(NamedTuple):
target: str
class Import(Import):
def __repr__(self) -> str:
return f'<Token {self.__repr__()}>' class Import(NamedTuple):
target: str
old_repr = Import.__repr__
def new_repr(self: Import) -> str:
return f'<Token {old_repr(self)}>'
Import.__repr__ = old_repr Setting This looks like a pretty niche problem that can be solved by a workaround. |
I'm pretty sure the first workaround will end up in a recursion limit excess.
There can never be a named tuple with a user-defined This change is not breaking and offers a clean solution to reusing the default implementation of I believe this is a fairly small addition and can be helpful once necessary. |
Oh, that's correct. Haven't taken that into account. Will look into this later, thanks! |
After some consideration, I also think we don't have to do this. We can, and I like it because I brought this idea, but it can also be confusing:
Instead, we can go with https://discuss.python.org/t/new-function-repr-args-in-pprint-or-reprlib/65193 which maybe does not offer as much reusability as the feature suggested in this issue, but it makes writing |
ISTM that is too small of a problem to warrant a potentially confusing API change. [Serhiy]
[Bartosz]
|
Feature or enhancement
Proposal:
This issue aims to propose a new feature on top of fixing gh-85795.
gh-85795 stems from the necessity of using
super()
inside methods oftyping.NamedTuple
subclasses.The documentation does not explicitly state it as unsupported, nor does it disrecommend the use of it.
Consequently, that behavior should be supported and the converse is considered a bug.
As in the StackOverflow question here, the developer tried their own implementation of
__repr__
in the subclass.And that's how I encountered the issue, too! I think it is very useful to be able to override the default
NamedTuple
representation and add additional info on top of it/tweak it somehow. For that reason, one would intuitively usesuper().__repr__()
, since we inherit fromNamedTuple
.However, that is impossible with the current model of behavior in typed named tuples.
Typed named tuples are constructed from the existing implementation of tuple subclass factory
collections.namedtuple
that does not insert anything other thantuple
above the final class in the MRO. Inheritance fromNamedTuple
is only possible due to__mro_entries__
hacks on thetyping.NamedTuple
function. To reference the default representation method of named tuples viasuper().__repr__()
, a middleman class representing the default implementations of named tuple methods between the underlying class andtuple
would be necessary. That is currently most likely impossible for backward compatibility reasons, something I learned from #126706 (comment), and does not appeal to me in terms of cost/benefit ratio.Hence, since
__repr__
is the only default method ofNamedTuple
useful to be referenced intyping.NamedTuple
subclasses, and all other come fromtuple
orobject
, I propose adding_repr
to the named tuple interface. The default__repr__
implementation would be a direct wrapper of it. Intyping.NamedTuple
,_repr
could not be overridden, but__repr__
could, to enable extendability with an optional reuse of_repr
.In
NamedTuple
subclasses allsuper().__repr__()
calls would resolve totuple.__repr__()
.This introduces no breaking changes, is additive only and retains the stable behavior of default
__repr__
of named tuples.With proper documentation, it can hint advanced named tuple users in how to create their own implementations of
__repr__
reusing the existing__repr__
default implementation.Example
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
_repr
method to named tuples #129353The text was updated successfully, but these errors were encountered: