This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: typing.NamedTuple does not support mixins
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: avrahami.ben, levkivskyi, rectalogic, rhettinger, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2019-04-03 13:07 by rectalogic, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 19363 merged serhiy.storchaka, 2020-04-04 14:51
Messages (4)
msg339390 - (view) Author: Andrew Wason (rectalogic) Date: 2019-04-03 13:07
Subclassing typing.NamedTuple an inheriting from a mixin class does not work. It does work for collections.namedtuple, and can be worked around by modifying typing.NamedTupleMeta:

>>> import collections
>>> import typing
>>>
>>>
>>> class Mixin:
...     def mixin(self):
...         return "mixin"
...
>>>
>>> class CollectionsNamedTuple(Mixin, collections.namedtuple('CollectionsNamedTuple', [
...     "a",
...     "b",
... ])):
...     pass
...
>>>
>>> class TypingNamedTuple(Mixin, typing.NamedTuple):
...     a: str
...     b: str
...
>>>
>>> class NamedTupleMeta(typing.NamedTupleMeta):
...     def __new__(cls, typename, bases, ns):
...         cls_obj = super().__new__(cls, typename + '_nm_base', bases, ns)
...         bases = bases + (cls_obj,)
...         return type(typename, bases, {})
...
>>>
>>> class FixedTypingNamedTuple(Mixin, metaclass=NamedTupleMeta):
...     a: str
...     b: str
...
>>>
>>> cnt = CollectionsNamedTuple("av", "bv")
>>> tnt = TypingNamedTuple("av", "bv")
>>> ftnt = FixedTypingNamedTuple("av", "bv")
>>>
>>> cnt.mixin()
'mixin'
>>> ftnt.mixin()
'mixin'
>>> tnt.mixin()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'TypingNamedTuple' object has no attribute 'mixin'
msg339546 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-04-06 21:34
Hm, it looks like we can support this. I however don't think the proposed "patch" is the right way to fix it, since this makes the implementation with and without a mixin quite different.

Also I am not sure I will have time to work on this in the nearest month.
msg365771 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-04-04 18:31
New changeset a94e6272f16381349dbed74cdb738ec8ae23b4fe by Serhiy Storchaka in branch 'master':
bpo-36517: Raise error on multiple inheritance with NamedTuple (GH-19363)
https://github.com/python/cpython/commit/a94e6272f16381349dbed74cdb738ec8ae23b4fe
msg386701 - (view) Author: Ben Avrahami (avrahami.ben) * Date: 2021-02-09 09:57
The patch PR blocks out a useful idiom: generic Nametuple

>>> class LLNode(NamedTuple, Generic[T]):
...     value :T
...     next: Optional[LLNode[T]]

I put forward that, at the least, NamedTuple should accept do-nothing bases like Generic.
History
Date User Action Args
2022-04-11 14:59:13adminsetgithub: 80698
2021-02-09 09:57:06avrahami.bensetnosy: + avrahami.ben
messages: + msg386701
2020-04-04 18:31:34serhiy.storchakasetmessages: + msg365771
2020-04-04 14:51:10serhiy.storchakasetkeywords: + patch
nosy: + serhiy.storchaka

pull_requests: + pull_request18725
stage: patch review
2019-04-06 21:34:20levkivskyisetmessages: + msg339546
2019-04-03 14:37:36gvanrossumsetnosy: - gvanrossum
2019-04-03 14:12:04matrixisesetnosy: + rhettinger
2019-04-03 13:15:33xtreaksetnosy: + gvanrossum, levkivskyi
2019-04-03 13:07:30rectalogiccreate