Optional[Any] is lost in cached run

[iFA88]

Greetings!

Found a weird mypy result to my code.
You can reproducate with the code:
(mypytest.py)

from typing import Dict, Any

def a(input:Dict[str, Any]) -> None:
	pass

def b(input:Any=None) -> None:
	a(input)

Run #1:

> mypy mypytest.py
mypytest.py:7: error: Argument 1 to "a" has incompatible type "Optional[Any]"; expected "Dict[str, Any]"
Found 1 error in 1 file (checked 1 source file)

Run #2:

> mypy mypytest.py --strict
Success: no issues found in 1 source file

I'm always use --strict for checking my code, but it seems in this case fails.

Environment:

• Python 3.9.2
• mypy 0.910
• Debian 11

[sobolevn]

Optional[Any] comes up as a problem way too often 😢

In this case it looks like it is just simplified to Any during second cached run.

[pranavrajpal]

This doesn't appear to have anything to do with whether the cache is populated. Running mypy without --strict consistently produces the first error regardless of whether the cache exists, and running mypy with --strict consistently produces no errors regardless of the cache. The difference in output between the 2 runs is because the second run added --strict.

From what I can tell, the reason that adding --strict causes the error to disappear is because it includes --no-implicit-optional. Without that, the Any is converted to Optional[Any] because the default value for the argument is None, leading to an error about using None where a dict is expected.

However, when --no-implicit-optional is enabled, mypy keeps the type of the argument as Any and doesn't show an error about the call to a because Any is compatible with anything. It also doesn't show an error about the None default value because None is a valid value for an argument of type Any.

The bug (or questionable behavior) is mypy changing the type of the argument from Any to Optional[Any] when implicit optional is enabled, considering that assigning None to Any is valid.

I'm not really sure what the correct behavior according to PEP 484 is. My reading of PEP 484 suggests that, when implicit optional is being used, any None default value causes the argument type to become Optional, regardless of the declared type of the argument, but that seems like the wrong approach in this case.

[erictraut]

This error is generated only if --implicit-option is used. This option is no longer the default.

I'm not able to repro the inconsistent behavior. It either generates the error (if --implicit-option is used) or does not generate the error (if --implicit-option isn't used) consistently across multiple runs. I suspect the bug was fixed somewhere along the way.