-
-
Notifications
You must be signed in to change notification settings - Fork 3k
crash when same file appears with different module names #4881
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
Comments
Yeah, I think when we detect this we should give an error. As you said this is also an issue in Python itself and there are some ideas for detecting and rejecting it there as well. (Though sadly I cannot find the thread about it.) |
Raising priority to high, since this is a crash, and it appeared several times. |
Hello, I created a small project that replicates this error: https://github.com/canassa/mypy-error What I don't understand is that I saw on some other comments that "this errors only happens when doing something nonsensical" like adding a package to Is there any workaround for this? This issue is blocking me from using mypy |
Even if we fix the bug, it's not clear that mypy would support this use case. It would probably produce an error instead of crashing. Why have you configured your project like this? Why can't you remove the |
You are correct, that I wasn't aware that's what was causing the crash. Thanks! that solves my problem |
Uh oh!
There was an error while loading. Please reload this page.
This bug found via a report from @eddieschoute
mypy crashes on the following
cmdline
test:This crashes with
Here, the "canonical" module name for
src/foo/bar.py
issrc.foo.bar
. But ifsrc
is on the search path, both python and mypy will also happily let it have the namefoo.bar
.In the test above, the inclusion on the command line results in
bar.py
being processed assrc.foo.bar
while the import forfoo.bar
ina.py
, combined withsrc
being on themypy_path
, also leads to it being processed asfoo.bar
. An error is generated in both, which trips an assert inErrors
as we try to add a new error to a file that has already had its error messages flushed to the user.One simple fix would be to track
flushed_files
by module id instead of file name, but it would probably be better to generate an error when a file appears multiple times with different module names, since it is unlikely to be intended?The text was updated successfully, but these errors were encountered: