Two issues with subclassing namedtuple-generated class and overriding __new__

[jstasiak]

Python 3.5.1, mypy 2f89c79.

Test code:

from typing import NamedTuple

Base = NamedTuple('Base', [('param', int)])


class Child(Base):

    def __new__(cls, param: int = 1) -> 'Child':
        return Base.__new__(cls, param)


print(Child())

Python result:

% python3 test2.py 
Child(param=1)

mypy output:

test2.py: note: In member "__new__" of class "Child":
test2.py:9: error: Too many arguments for "__new__" of "object"
test2.py: note: At top level:
test2.py:12: error: Too few arguments for "Child"

I poked around in the code a bit and I believe I managed to narrow this down to the following difference:

• The code above depends on the namedtuple-generated class to have __new__ defined (CPython: https://github.com/python/cpython/blob/9967d6c1053f186f3b3d118ac336a03752efec32/Lib/collections/__init__.py#L316)
• mypy treats namedtuple definitions as if they were overriding __init__ instead (

  mypy/mypy/semanal.py

  Line 1444 in 2f89c79

  symbols['__init__'] = SymbolTableNode(MDEF, init)

  )

[gvanrossum]

Yeah, mypy should probably define NamedTuple in terms of __new__, not __init__. There are some deficiencies in mypy's __new__ support though that may make this not simple until they are first fixed.

[gvanrossum]

In particular #1021 looks like a dependency for this. (And we haven't assigned that a milestone yet, so we can't assign a milestone here either.)

[gvanrossum]

I propose to bump the priority here. This seems a real problem to some of our users.

[ilevkivskyi]

I propose to bump the priority here. This seems a real problem to some of our users.

Sure, although TBH this will not help much, we are already overloaded with work.

[gvanrossum]

Indeed. :-(

And aggressively critical users don't motivate me.

[gvanrossum]

I don't think python/typeshed#2467 actually fixed this (the auto fix triggered by accident).

[JelleZijlstra]

Oops, sorry for that and thanks for fixing.