Skip to content
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

Self-referring NamedTuples #2399

Closed
not-raspberry opened this issue Nov 4, 2016 · 2 comments · Fixed by #3952
Closed

Self-referring NamedTuples #2399

not-raspberry opened this issue Nov 4, 2016 · 2 comments · Fixed by #3952

Comments

@not-raspberry
Copy link

node.py:

"""Tree node namedtuple demo."""
from typing import Tuple, NamedTuple



Node = NamedTuple(
    'Node',
    [
        ('name', str),
        ('children', Tuple['Node', ...]),
    ])

What happens:

$ mypy node.py
node.py:9: error: Invalid type "node.Node"
$ mypy --version
mypy 0.4.5

What should happen:

The checker should recognise the name of the NamedTuple even inside its definition.

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 4, 2016

Yeah, this is a known issue and it also affects type aliases among other things. Not sure if there's an existing github issue about this in particular, though.

@gvanrossum
Copy link
Member

Probably #731, though I don't know if there's a special issue with NamedTuple.

This type of issue keeps coming up, I propose that we put this in the queue for the 0.5 milestone.

@gvanrossum gvanrossum added this to the 0.5 milestone Nov 4, 2016
@gvanrossum gvanrossum removed this from the 0.5 milestone Mar 29, 2017
JukkaL pushed a commit that referenced this issue Sep 27, 2017
Forward references didn't work with anything apart from classes, for example 
this didn't work:

```
x: A
A = NamedTuple('A', [('x', int)])
```

The same situation was with `TypedDict`, `NewType`, and type aliases. The 
root problem is that these synthetic types are neither detected in first pass, 
nor fixed in third pass. In certain cases this can lead to crashes (first six issues 
below are various crash scenarios). This fixes these crashes by applying some 
additional patches after third pass.

Here is the summary of the PR:

* New simple wrapper type `ForwardRef` with only one field `link` is introduced 
  (with updates to type visitors)
* When an unknown type is found in second pass, the corresponding 
  `UnboundType` is wrapped in `ForwardRef`, it is given a "second chance" in 
  third pass.
* After third pass I record the "suspicious" nodes, where forward references and 
  synthetic types have been encountered and append patches (callbacks) to fix 
  them after third pass. Patches use the new visitor `TypeReplacer` (which is the 
  core of this PR).

Fixes #3340
Fixes #3419
Fixes #3674
Fixes #3685
Fixes #3799
Fixes #3836
Fixes #3881
Fixes #867
Fixes #2241
Fixes #2399
Fixes #1701
Fixes #3016
Fixes #3054
Fixes #2762
Fixes #3575
Fixes #3990
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants