{"action":"created","issue":{"url":"https://api.github.com/repos/python/mypy/issues/4834","repository_url":"https://api.github.com/repos/python/mypy","labels_url":"https://api.github.com/repos/python/mypy/issues/4834/labels{/name}","comments_url":"https://api.github.com/repos/python/mypy/issues/4834/comments","events_url":"https://api.github.com/repos/python/mypy/issues/4834/events","html_url":"https://github.com/python/mypy/issues/4834","id":310369179,"number":4834,"title":"generic class attributes with unions become object on subclasses","user":{"login":"chadrik","id":63251,"avatar_url":"https://avatars1.githubusercontent.com/u/63251?v=4","gravatar_id":"","url":"https://api.github.com/users/chadrik","html_url":"https://github.com/chadrik","followers_url":"https://api.github.com/users/chadrik/followers","following_url":"https://api.github.com/users/chadrik/following{/other_user}","gists_url":"https://api.github.com/users/chadrik/gists{/gist_id}","starred_url":"https://api.github.com/users/chadrik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chadrik/subscriptions","organizations_url":"https://api.github.com/users/chadrik/orgs","repos_url":"https://api.github.com/users/chadrik/repos","events_url":"https://api.github.com/users/chadrik/events{/privacy}","received_events_url":"https://api.github.com/users/chadrik/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-04-02T01:02:51Z","updated_at":"2018-04-02T10:04:17Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I'm not sure if this is a bug or not, but if it is by design it would be great if it was covered in the docs, as I found it confusing:\r\n\r\n```python\r\nfrom typing import *\r\n\r\nclass A:\r\n    a = None  # type: List[str]\r\n    b = None  # type: List[Union[str, int]]\r\n    c = None  # type: List[Union[str, int]]\r\n    d = None  # type: Sequence[Union[str, int]]\r\n\r\nclass B(A):\r\n    a = ['foo']\r\n    b = ['foo']\r\n    c = ['foo', 1]\r\n    d = ['foo', 1]\r\n\r\nreveal_type(B.a)  # 'builtins.list[builtins.str*]'\r\nreveal_type(B.b)  # 'builtins.list[builtins.str*]'\r\nreveal_type(B.c)  # 'builtins.list[builtins.object*]'\r\nreveal_type(B.d)  # 'builtins.list[builtins.object*]'\r\n```\r\n\r\nI expected `c` and `d` to remain unions.  \r\n"},"comment":{"url":"https://api.github.com/repos/python/mypy/issues/comments/377899363","html_url":"https://github.com/python/mypy/issues/4834#issuecomment-377899363","issue_url":"https://api.github.com/repos/python/mypy/issues/4834","id":377899363,"user":{"login":"ilevkivskyi","id":12005495,"avatar_url":"https://avatars1.githubusercontent.com/u/12005495?v=4","gravatar_id":"","url":"https://api.github.com/users/ilevkivskyi","html_url":"https://github.com/ilevkivskyi","followers_url":"https://api.github.com/users/ilevkivskyi/followers","following_url":"https://api.github.com/users/ilevkivskyi/following{/other_user}","gists_url":"https://api.github.com/users/ilevkivskyi/gists{/gist_id}","starred_url":"https://api.github.com/users/ilevkivskyi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ilevkivskyi/subscriptions","organizations_url":"https://api.github.com/users/ilevkivskyi/orgs","repos_url":"https://api.github.com/users/ilevkivskyi/repos","events_url":"https://api.github.com/users/ilevkivskyi/events{/privacy}","received_events_url":"https://api.github.com/users/ilevkivskyi/received_events","type":"User","site_admin":false},"created_at":"2018-04-02T10:04:17Z","updated_at":"2018-04-02T10:04:17Z","author_association":"COLLABORATOR","body":"What I see here is a bigger bug, namely it looks like we are currently don't check Liskov for inferred types. I think this may be because we currently don't have backtracking in our inference engine, so currently we will have some false positives. Another thing that we can do is to use explicit (i.e. declared) or even implicit (i.e. inferred) suprtype type as a context for inference. This however may lead to wider types than one would expect. So that I think ultimately we may need both backtracking and using supertype context to conveniently (for user) treat such situations.\r\n\r\nThese are however two very different scale tasks, so I would propose to just go with using explicit supertype context (this seems to be pretty easy). Actually, if we are going to prohibit covariant subtyping of mutable attributes at some point, just using supertype context would be the final/full solution. @JukkaL what do you think?"}}
{"actor":{"display_login":"ilevkivskyi"}}