I ran into this issue testing a pre-release of 1.3 and it has created enough confusion on the team that I'm not sure we can roll it out until this is fixed. I would love to see this merged before release.

The quotes shouldn't matter as this is a stub file, which isn't evaluated. The mutually recursive definition of Iterable and Iterator is indeed annoying to deal with, but mypy should be able to handle it.

I'd like to try to help with this issue, and have some time next week.

From what I understand, the PR fixes the underlying issue, but causes some apparently unrelated tests to fail in a surprising way. (The odd behaviour is limited to tests and doesn't happen if we run mypy for real.)

I'm assuming this is a problem with the test machinery, and in particular with test fixtures that attempt to import Iterator.

My plan next week is to understand better what's going on by stepping through the test run in a debugger, but if anyone has any inkling as to what might be going on I'd be very grateful for any pointers. @chadrik or @JelleZijlstra I don't suppose you have any idea?

I've created a simple test case to show what is breaking. This test passes (but it shouldn't).

[case testDemo]
[file a.py]
[file a.py.2]
# Comment to trigger reprocessing.
[builtins fixtures/list.pyi]
[out]
==
builtins.pyi:18: error: Name "Iterator" is not defined
builtins.pyi:18: note: Did you forget to import it from "typing"? (Suggestion: "from typing import Iterator")

This test is simulating the addition of a comment to an otherwise empty file. We are using the list.pyi fixture. The first time the module is checked (above the ==) there are no errors, but the second time (below the ==) we get the "Iterator" is not defined error.

I'll continue to try to understand why this is...

Good news - I think I've got somewhere. This WIP commit gets the number of failing tests down to only 3. 🥳

Background

I noticed while debugging that there were some additional errors in the error list following the first check run. These aren't surfaced anywhere obvious, I happened to find these by putting a breakpoint in the final statement of mypy.dmypy_server.Server.initialize_fine_grained and then drilling down to
self.fine_grained_manager.manager.errors.error_info_map.

Most of the errors were along these lines:

'Method "__getitem__" is not using @override but is overriding a method in class "typing.Sequence"'
'Method "__iter__" is not using @override but is overriding a method in class "typing.Iterable"'

These errors aren't present when I run it on master.

How I fixed it

I'm not sure if it's the correct thing to do, but I found adding from typing_extensions import override and then decorating the methods in question made the tests pass.

@chadrik @JelleZijlstra Do you have any concerns with this as a fix? If so, please advise what would be a better thing to do.

There were a couple of other test cases where instead the fix seemed to be just to add the appropriate builtins declaration in the test case.

Remaining failures

The last three are a bit different - I'll continue to look at these tomorrow.

Further context

The reason for the more visible Iterator errors seems to be that the semantic analyzer's globals aren't populated with the typing module when the second pass runs. I am not sure how this relates to the fix in question, I've only got limited understanding of what's going on so far.

@CoolCat467 I've reproduced a crash on the master branch using your example. The crash I got wasn't exactly the same, but it's possible that's because I didn't have exactly the same setup as you.

I don't think that the crash I got is related to these changes, though as I said, I didn't get the same one as you.

I've boiled it down to a minimal example, and added details of the crash in #14645 (comment)

@CoolCat467 I'm not able to reproduce your issue with the disappearing messages using the script in that repo.

Can I please ask for detailed instructions on how to reproduce it?

@CoolCat467 I'm not able to reproduce your issue with the disappearing messages using the script in that repo.

Can I please ask for detailed instructions on how to reproduce it?

I have now updated https://github.com/CoolCat467/NEAT-Template-Python/dmypy_test.sh to use absolute paths and I get the key error reliably. I would be happy to help if you need more details!

Edit: I think the important detail was the fact I am telling dmypy absolute paths, because my use case of dmypy is as a code editor extension (idlemypyextension), where it might be quite important to tell the mypy daemon exactly which file we want it to check, because potentially the user changes projects without restarting the daemon and they might happen to have files named exactly the same way or whatnot.

@CoolCat467 Thank you for the clarification. I've got that working now, and can reproduce the dropped errors (on this branch and master). I'll try to turn this into a minimal test case.

Curiously, I'm now not seeing the crash on the third command, but I'll come back to that later.

The best minimal example I have so far:

pyproject.toml:

[build-system]
requires = ["setuptools >= 64"]
build-backend = "setuptools.build_meta"

[project]
name = "dmypy_example"
version = "0.0.1"
dependencies = []

src/foo.py (see notes at end):

a: str = 1

Commands:

# Create a new Python 3.12 virtualenv, then:
pip install --editable .
dmypy run --export-types $(pwd)/src/foo.py
dmypy run --export-types $(pwd)/src/foo.py

Results:

$ pip install --editable .
...

$ dmypy run --export-types $(pwd)/src/foo.py
Daemon started
src/foo.py:1: error: Incompatible types in assignment (expression has type "int", variable has type "str")  [assignment]
Found 1 error in 1 file (checked 1 source file)

$ dmypy run --export-types $(pwd)/src/foo.py
Success: no issues found in 1 source file

Notes:

• If I use a name other than src this doesn't seem to work. This is so odd that I feel like I must be doing something wrong.
• This doesn't happen if we don't pip install.
• It doesn't matter what the error in foo.py is. All errors seem to disappear in the second run.
• This happens on the master branch of Mypy too.

My conclusion:

It's disappointing that this branch doesn't fix this error, but I don't think that it's caused by this branch, so perhaps we should consider this a new bug for handling separately?

It's disappointing that this branch doesn't fix this error, but I don't think that it's caused by this branch, so perhaps we should consider this a new bug for handling separately?

Yea, I think it would make sense to make a new issue for this in particular.

If I use a name other than src this doesn't seem to work. This is so odd that I feel like I must be doing something wrong.

I think this might be due to the project structure pip expects, but not completely sure

Also side note, thank you for showing the use of pwd, I wasn't aware that was a thing, that's super helpful instead of using python to figure out the path!

If I use a name other than src this doesn't seem to work. This is so odd that I feel like I must be doing something wrong.

I think this might be due to the project structure pip expects, but not completely sure

As far as I know, src is nothing to do with pip, it's a convention for structuring code that has been gaining momentum in the last few years. (Not a good one, in my opinion, but that's off topic.)

thank you for showing the use of pwd

I'm glad you found it useful! 🙂

It's disappointing that this branch doesn't fix this error, but I don't think that it's caused by this branch, so perhaps we should consider this a new bug for handling separately?

Yea, I think it would make sense to make a new issue for this in particular.

Thanks! I've opened a new issue so we can track it there. #16768

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Hi all! It's been a while since I've had a look at this (I got a bit overwhelmed with it, TBH).

I notice that this was considered for release in 1.9, but wasn't merged because "while the PR itself is apparently ok, it doesn't actually fix the issue completely that its trying to address".

Am I right in saying that the issue discovered in this comment is the blocker? Before I go about investigating that, are there any other blockers that we're aware of?

@jhance I wonder if you're able to help me answer the question above, so that I might be able to continue on this?

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

OMG you merged it! I love you!