Skip to content

Behaviour of Type[Any] #3098

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

Closed
dmoisset opened this issue Mar 31, 2017 · 2 comments · Fixed by #3246
Closed

Behaviour of Type[Any] #3098

dmoisset opened this issue Mar 31, 2017 · 2 comments · Fixed by #3246
Labels
bug mypy got something wrong priority-0-high

Comments

@dmoisset
Copy link
Contributor

Currently a Type[Any] is considered to have the same attributes as Type[object]. However, actually it probably has many attributes that could be used, especially when the Any comes from a module without stubs. Consider the following example:

from typing import Type
from some_module import Candy, Lollipop  # some_module has no stubs/annotations

class CandyFactory:
    manufactured_candy: Type[Candy]

cf = CandyFactory()
cf.manufactured_candy = Lollipop

print(cf.manufactured_candy.sugar_level)

Then running:

$ mypy --ignore-missing-imports candy.py 
candy.py:11: error: Type[Any] has no attribute "sugar_level"

Which seems to go a bit against the idea of gradual typing and intention of Any.

One possible solution is to consider that Type[Any] == Any, I think this actually would not miss anything that could be catched now, while reducing false positives.

@JukkaL
Copy link
Collaborator

JukkaL commented Mar 31, 2017

I've wondered myself about how Type[Any] should behave, and your reasoning sounds about right. It should probably not be the same as Any with respect to subtyping/compatibility, only with respect to attribute access. Passing Type[Any] to a function that excepts an int should still be rejected (and vice versa).

@JukkaL
Copy link
Collaborator

JukkaL commented Apr 25, 2017

I'm spelling out explicitly what should change:

For a value x of type Type[Any], mypy should allow arbitrary attribute access like x.foobar, and the result type should be Any.

dmoisset added a commit to dmoisset/mypy that referenced this issue Apr 25, 2017
@JukkaL JukkaL added bug mypy got something wrong and removed needs discussion labels Apr 26, 2017
JukkaL pushed a commit that referenced this issue Apr 26, 2017
* Handle member access on Type[Any], fix #3098

* Add test on member assignment

* Fallback to builtin.type attributes if possible when accessing members of Type[Any]

* Add type.pyi fixture to make test pass
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong priority-0-high
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants