{"action":"opened","issue":{"url":"https://api.github.com/repos/python/mypy/issues/2897","repository_url":"https://api.github.com/repos/python/mypy","labels_url":"https://api.github.com/repos/python/mypy/issues/2897/labels{/name}","comments_url":"https://api.github.com/repos/python/mypy/issues/2897/comments","events_url":"https://api.github.com/repos/python/mypy/issues/2897/events","html_url":"https://github.com/python/mypy/issues/2897","id":209918361,"number":2897,"title":"Organizing stubs for different versions of supported libraries ","user":{"login":"pkch","id":1593648,"avatar_url":"https://avatars.githubusercontent.com/u/1593648?v=3","gravatar_id":"","url":"https://api.github.com/users/pkch","html_url":"https://github.com/pkch","followers_url":"https://api.github.com/users/pkch/followers","following_url":"https://api.github.com/users/pkch/following{/other_user}","gists_url":"https://api.github.com/users/pkch/gists{/gist_id}","starred_url":"https://api.github.com/users/pkch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pkch/subscriptions","organizations_url":"https://api.github.com/users/pkch/orgs","repos_url":"https://api.github.com/users/pkch/repos","events_url":"https://api.github.com/users/pkch/events{/privacy}","received_events_url":"https://api.github.com/users/pkch/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-02-23T23:41:35Z","updated_at":"2017-02-23T23:41:35Z","closed_at":null,"body":"The organization of typeshed folders is described in `build.py: default_lib_path`:\r\n\r\n```\r\n    # We allow a module for e.g. version 3.5 to be in 3.4/. The assumption\r\n    # is that a module added with 3.4 will still be present in Python 3.5.\r\n```\r\n\r\nThis is not 100% clear. It is very common for libraries (like `enum`) to be updated with addition of new methods or module level objects. How is the stub supposed to be updated? Adding `enum.auto` to the stub in `3.4/` subfolder doesn't seem right. Should a brand new `enum.pyi` be added to `3.6/` subfolder? If that's the case, almost every stub would have to appear in multiple subfolders, so why not make things simpler and require that each stub shows up in each version of python in which it exists?\r\n\r\nCode duplication is annoying, of course. While we wouldn't worry that there is code duplication between python 3.4 and python 3.6, that's because version control takes care of that. On the other hand, these versioned stubs, while logically no different than the versions of the libraries they describe, are unfortunately not maintained in the same repos as the corresponding libraries, so they don't get the benefit of version control.\r\n\r\nI don't know of a perfect solution to code duplication, but one option is allow incremental updates across versions. That is, let's say `3.4/enum.py` could be loaded first, and then (if appropriate) `3.6/enum.pyi` could be loaded - adding new and overwriting (or even deleting) old type definitions."}}
{"actor":{"display_login":"pkch"}}