{"action":"created","issue":{"url":"https://api.github.com/repos/python/typing/issues/241","repository_url":"https://api.github.com/repos/python/typing","labels_url":"https://api.github.com/repos/python/typing/issues/241/labels{/name}","comments_url":"https://api.github.com/repos/python/typing/issues/241/comments","events_url":"https://api.github.com/repos/python/typing/issues/241/events","html_url":"https://github.com/python/typing/issues/241","id":164525166,"number":241,"title":"Allow subclassing without supertyping","user":{"login":"dmoisset","id":200733,"avatar_url":"https://avatars.githubusercontent.com/u/200733?v=3","gravatar_id":"","url":"https://api.github.com/users/dmoisset","html_url":"https://github.com/dmoisset","followers_url":"https://api.github.com/users/dmoisset/followers","following_url":"https://api.github.com/users/dmoisset/following{/other_user}","gists_url":"https://api.github.com/users/dmoisset/gists{/gist_id}","starred_url":"https://api.github.com/users/dmoisset/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dmoisset/subscriptions","organizations_url":"https://api.github.com/users/dmoisset/orgs","repos_url":"https://api.github.com/users/dmoisset/repos","events_url":"https://api.github.com/users/dmoisset/events{/privacy}","received_events_url":"https://api.github.com/users/dmoisset/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2016-07-08T12:57:10Z","updated_at":"2016-07-14T16:28:19Z","closed_at":null,"body":"This issue comes from python/mypy#1237. I'll try to make a summary of the discussion here\r\n\r\nSome one reported an issue with an artificial example (https://github.com/python/mypy/issues/1237#issue-136162181):\r\n\r\n```python\r\nclass Foo:\r\n    def factory(self) -> str:\r\n        return 'Hello'\r\n\r\nclass Bar(Foo):\r\n    def factory(self) -> int:\r\n        return 10\r\n```\r\nand then with the following stub files (https://github.com/python/mypy/issues/1237#issuecomment-188710925):\r\n\r\n```python\r\nclass QPixmap(QPaintDevice):\r\n    def swap(self, other: 'QPixmap') -> None: ...\r\n\r\nclass QBitmap(QPixmap):\r\n    def swap(self, other: 'QBitmap') -> None: ...\r\n```\r\n\r\nWhich mypy currently reports as erroneous: `Argument 1 of \"swap\" incompatible with supertype \"QPixmap\"`\r\n\r\nThese were initially was argued to be a correct error because they violate Liskov Substitution Principle (the same case by a change of return type, the second is a covariant argument change). The problem in this scenario is that the actual classes are not meant to be substituted (the first example is actually a wrapper for a non-virtual C++ function so they're not substitutable, and the second aren't supposed to be mixed together, just reuse part of the code). (see https://github.com/python/mypy/issues/1237#issuecomment-189490903)\r\n\r\nThere was also a suggestion that allow covariant args explicitly (in the same way that Eiffel allows it and adds a runtime check) with a decorator\r\n\r\n```python\r\nclass QBitmap(QPixmap):\r\n    @covariant_args\r\n    def swap(self, other: 'QBitmap') -> None: ...\r\n```\r\n\r\nMy proposal instead was add what some dialects of Eiffel call \"non-conforming inheritance\" (\"conforms\" is the Eiffel word for what PEP-483 calls \"is-consistent-with\"). It is essentially a mechanism to use subclassing just as a way to get the implementation from the superclass without creating a subtyping relation between them. See https://github.com/python/mypy/issues/1237#issuecomment-231199419 for a detailed explanation.\r\n\r\nThe proposal is to haven `Implementation` in typing so you can write:\r\n\r\n```python\r\nclass QBitmap(Implementation[QPixmap]):\r\n    def swap(self, other: 'QBitmap') -> None: ...\r\n```\r\n\r\nwhich just defines a `QBitmap` class with all the mothods copied from `QPixmap`, but without making one a subtype of the other. In runtime we can just make `Implementation[QPixmap] == QPixmap`\r\n"},"comment":{"url":"https://api.github.com/repos/python/typing/issues/comments/232717908","html_url":"https://github.com/python/typing/issues/241#issuecomment-232717908","issue_url":"https://api.github.com/repos/python/typing/issues/241","id":232717908,"user":{"login":"ilevkivskyi","id":12005495,"avatar_url":"https://avatars.githubusercontent.com/u/12005495?v=3","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":"2016-07-14T16:28:19Z","updated_at":"2016-07-14T16:28:19Z","body":"@gvanrossum Indeed, there is not much could be done. But I don't think this is bad. As with ``Any`` or ``# type: ignore``, people who are going to use this feature know what they do. More important is that ``Implementation`` provides more precise typechecking, more \"granularity\", and probably a bit more safety than ``Any``."}}
{"actor":{"display_login":"ilevkivskyi"}}