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

Optional[Any] is lost in cached run #11834

Closed
iFA88 opened this issue Dec 23, 2021 · 3 comments
Closed

Optional[Any] is lost in cached run #11834

iFA88 opened this issue Dec 23, 2021 · 3 comments
Labels

Comments

@iFA88
Copy link

iFA88 commented Dec 23, 2021

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
@iFA88 iFA88 added the bug mypy got something wrong label Dec 23, 2021
@sobolevn
Copy link
Member

sobolevn commented Dec 23, 2021

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.

@JelleZijlstra JelleZijlstra changed the title Strict is not so strict Optional[Any] is lost in cached run Dec 23, 2021
@pranavrajpal
Copy link
Contributor

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants