Named tuples in import cycles still fail sometimes

It looks like issue #3054 was not completely fixed. Namely, in some scenarios named tuples
in import cycles result in Invalid type. For example, checking this file

import posix

results in

typeshed/stdlib/3/os/__init__.pyi:331: error: Invalid type "posix.uname_result"
typeshed/stdlib/3/os/__init__.pyi:599: error: Invalid type "posix.times_result"
typeshed/stdlib/3/os/__init__.pyi:605: error: Invalid type "posix.waitid_result"
typeshed/stdlib/3/os/__init__.pyi:622: error: Invalid type "posix.sched_param"
typeshed/stdlib/3/os/__init__.pyi:624: error: Invalid type "posix.sched_param"
typeshed/stdlib/3/os/__init__.pyi:625: error: Invalid type "posix.sched_param"

Note that the above "invalid" types are all named tuples and there is an import cycle os <-> posix. Interestingly, import os and from os import * both typecheck cleanly.

I haven't yet tried to find a simple repro (not involving typeshed).

Somehow this breaks typshed build since recently, so I raised priority to high.

move os.stat_result into posix stub

move os.stat_result into posix stub (#1818)

I deleted code from the typestub until I got, in posix.pyi,

from os import stat_result

# This was NamedTuple('etc'), but that doesn't affect the error.
uname_result = "dummy" # E: Invalid type "posix.uname_result"

and in os/__init__.pyi,

stat_result = "dummy"
from posix import T
def uname() -> uname_result: ...

so there is something fishy with the way circular imports are resolved, but it doesn't seem to me to involve NamedTuple specifically.

Actually, I think this is just a case of the bad circular import discussed in https://stackoverflow.com/a/40094439/5749914 (posix.py is Y.py, os/__init__.py is X.py)

Mypy executes from os import stat_result, but then proceeds to import the rest of os/__init__.pyi, resulting in an error when uname_result is undefined.

Do note that circular dependencies at run-time work differently than in mypy's analysis.

Yes, but if it wouldn't work by python's runtime, I figure there is no reason to expect it to work for mypy, at least in this case IMO.

@ilevkivskyi

@ilevkivskyi I think this ought to be closed because the behavior is reasonable, what do you think?

@ilevkivskyi

@ilevkivskyi Can you come up with a self-contained example that reproduces the problem? I'd like to know if #4695 fixed this issue, and if not, I'll look at fixing this.

@JukkaL

@JukkaL Unfortunately, I didn't yet find a simple repro, but there is a "dirty" way of testing it by just using the offending typeshed commit 81751306883. I just tried it, and the error is still present, it was not fixed by #4695.

@JukkaL

@JukkaL

and if not, I'll look at fixing this.

OK, I will spend some more time now to find a simple repro for you.

So, here is a simplest repro I can find:

# file a.py
class C:
    pass

from b import tp
x: tp

# file b.py
from a import C
from typing import NamedTuple

tp = NamedTuple('tp', [('x', int)])

Then one needs to run mypy b.py and get:

a.py:5: error: Invalid type "b.tp"

Note that error disappears if tp is a normal class.

Also note that the same error also appears if one or both of a and b are packages and use named tuples in __init__.py.

Update imported Vars in the third pass (#5635)

Navigation Menu

Repository navigation

Named tuples in import cycles still fail sometimes #4442

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Named tuples in import cycles still fail sometimes #4442

Description

Activity

ilevkivskyi commented on Jan 9, 2018

elliott-beach commented on Jan 10, 2018

elliott-beach commented on Jan 10, 2018

gvanrossum commented on Jan 10, 2018

elliott-beach commented on Jan 10, 2018

elliott-beach commented on Jan 11, 2018

JukkaL commented on Mar 8, 2018

ilevkivskyi commented on Mar 9, 2018

ilevkivskyi commented on Mar 9, 2018

ilevkivskyi commented on Mar 9, 2018

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions