{"action":"created","issue":{"url":"https://api.github.com/repos/JukkaL/mypy/issues/1065","labels_url":"https://api.github.com/repos/JukkaL/mypy/issues/1065/labels{/name}","comments_url":"https://api.github.com/repos/JukkaL/mypy/issues/1065/comments","events_url":"https://api.github.com/repos/JukkaL/mypy/issues/1065/events","html_url":"https://github.com/JukkaL/mypy/issues/1065","id":121616032,"number":1065,"title":"Figure out story about diamond inheritance","user":{"login":"gnprice","id":28173,"avatar_url":"https://avatars.githubusercontent.com/u/28173?v=3","gravatar_id":"","url":"https://api.github.com/users/gnprice","html_url":"https://github.com/gnprice","followers_url":"https://api.github.com/users/gnprice/followers","following_url":"https://api.github.com/users/gnprice/following{/other_user}","gists_url":"https://api.github.com/users/gnprice/gists{/gist_id}","starred_url":"https://api.github.com/users/gnprice/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gnprice/subscriptions","organizations_url":"https://api.github.com/users/gnprice/orgs","repos_url":"https://api.github.com/users/gnprice/repos","events_url":"https://api.github.com/users/gnprice/events{/privacy}","received_events_url":"https://api.github.com/users/gnprice/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/JukkaL/mypy/labels/feature","name":"feature","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-12-11T01:30:00Z","updated_at":"2015-12-13T23:24:46Z","closed_at":null,"body":"In `mypy/maptype.py`, we have a function `class_derivation_paths` that finds all the paths up the hierarchy from a derived class to a given ancestor class. The code implicitly assumes that this function will only ever return a single path, for example by silently taking the first element of a list derived from its result and dropping the rest:\r\n```\r\n    return map_instance_to_supertypes(instance, superclass)[0]\r\n```\r\nAnd indeed there are a couple of assertions in comments in the code that this function should only ever find a single path:\r\n```\r\n    # FIX: Currently we should only have one supertype per interface, so no\r\n    #      need to return an array\r\n[...]\r\n    # FIX: Currently we might only ever have a single path, so this could be\r\n    #      simplified\r\n```\r\n\r\nBut this doesn't seem to be true! In fact, if we set up the classic diamond inheritance pattern:\r\n```\r\n  A\r\n / \\\r\nB   C\r\n \\ /\r\n  D\r\n```\r\nthen we do in fact get two paths, one through `B` and one through `C`. Demonstrated by adding an assert and a triggering test case here: https://github.com/gnprice/mypy/commit/a85876521\r\nwhich produces this exception:\r\n```\r\nAssertionError: [[<TypeInfo __main__.B>, <TypeInfo __main__.A>], [<TypeInfo __main__.C>, <TypeInfo __main__.A>]]\r\n```\r\n\r\nWhat should our approach to this situation be?\r\n\r\nIn roughly increasing order of semantic and implementation complexity, some options include\r\n* forbid this situation -- require that there's only a single inheritance path from a given derived class to a given ancestor, and say that code that uses diamond inheritance can't be typed\r\n* allow diamond inheritance only if the ancestor is not generic\r\n* allow diamond inheritance only if all the inheritance paths can be verified, just from the class definitions, to always result in the same instance of the ancestor for any instance of the derived\r\n* allow diamond inheritance only if the *actual* instances of the derived class that we encounter each result in a single instance of the ancestor across all inheritance paths (this is uncomfortably reminiscent of C++ templates)\r\n* something even more complicated that allows inheriting from several different instances of the same ancestor\r\n\r\nI'm inclined to start with option 1, as it's super simple to understand and to implement, and see if that ever poses a problem. Maybe nobody actually uses diamond inheritance in code they want to try to type; it's a pretty tricky pattern in the first place. If we want to do this, we should detect the situation up front (like in `verify_base_classes` in semanal.py) and give an appropriate error.\r\n\r\nOption 2 is also super simple to implement, if people use diamond inheritance but they don't need generics with it. Somewhat less satisfying as a rule for the user.\r\n\r\nI'd be kind of concerned if we find ourselves starting to think we need one of the more complex options.\r\n"},"comment":{"url":"https://api.github.com/repos/JukkaL/mypy/issues/comments/164310122","html_url":"https://github.com/JukkaL/mypy/issues/1065#issuecomment-164310122","issue_url":"https://api.github.com/repos/JukkaL/mypy/issues/1065","id":164310122,"user":{"login":"gvanrossum","id":2894642,"avatar_url":"https://avatars.githubusercontent.com/u/2894642?v=3","gravatar_id":"","url":"https://api.github.com/users/gvanrossum","html_url":"https://github.com/gvanrossum","followers_url":"https://api.github.com/users/gvanrossum/followers","following_url":"https://api.github.com/users/gvanrossum/following{/other_user}","gists_url":"https://api.github.com/users/gvanrossum/gists{/gist_id}","starred_url":"https://api.github.com/users/gvanrossum/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gvanrossum/subscriptions","organizations_url":"https://api.github.com/users/gvanrossum/orgs","repos_url":"https://api.github.com/users/gvanrossum/repos","events_url":"https://api.github.com/users/gvanrossum/events{/privacy}","received_events_url":"https://api.github.com/users/gvanrossum/received_events","type":"User","site_admin":false},"created_at":"2015-12-13T23:24:46Z","updated_at":"2015-12-13T23:24:46Z","body":"Yeah, there's something fishy with typing.py here. :-( I think there's even\nan issue about it in https://github.com/ambv/typehinting/issues but I've\nlost track of which one it is.\n"}}