{"action":"created","issue":{"url":"https://api.github.com/repos/python/mypy/issues/2150","repository_url":"https://api.github.com/repos/python/mypy","labels_url":"https://api.github.com/repos/python/mypy/issues/2150/labels{/name}","comments_url":"https://api.github.com/repos/python/mypy/issues/2150/comments","events_url":"https://api.github.com/repos/python/mypy/issues/2150/events","html_url":"https://github.com/python/mypy/issues/2150","id":177602649,"number":2150,"title":"Discussion: frontend, backend and \"runtime\"","user":{"login":"elazarg","id":5108069,"avatar_url":"https://avatars.githubusercontent.com/u/5108069?v=3","gravatar_id":"","url":"https://api.github.com/users/elazarg","html_url":"https://github.com/elazarg","followers_url":"https://api.github.com/users/elazarg/followers","following_url":"https://api.github.com/users/elazarg/following{/other_user}","gists_url":"https://api.github.com/users/elazarg/gists{/gist_id}","starred_url":"https://api.github.com/users/elazarg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/elazarg/subscriptions","organizations_url":"https://api.github.com/users/elazarg/orgs","repos_url":"https://api.github.com/users/elazarg/repos","events_url":"https://api.github.com/users/elazarg/events{/privacy}","received_events_url":"https://api.github.com/users/elazarg/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/python/mypy/labels/needs%20discussion","name":"needs discussion","color":"bfdadc"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/python/mypy/milestones/7","html_url":"https://github.com/python/mypy/milestones/Undetermined%20priority","labels_url":"https://api.github.com/repos/python/mypy/milestones/7/labels","id":1690406,"number":7,"title":"Undetermined priority","description":"Milestone for issues to which we can't assign a priority yet because we don't have enough information.","creator":{"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},"open_issues":28,"closed_issues":10,"state":"open","created_at":"2016-04-07T17:56:48Z","updated_at":"2016-09-18T17:45:20Z","due_on":null,"closed_at":null},"comments":2,"created_at":"2016-09-17T19:31:30Z","updated_at":"2016-09-18T20:16:25Z","closed_at":null,"body":"<small>This is an idea for the long-run, not a \"please do now\" request. I don't know if the right place for such discussion is here; let me know.</small>\r\n\r\nI think the architecture of the system should be more modular, comprised of three independent parts, with well defined interface:\r\n1. Frontend - parsing and semantic analysis\r\n2. Backend - translating the output of the front end to \"assembly language\" of type checkers, which is some constraint language (textual language)\r\n3. Runtime - evaluating the contsraints and emitting error messages\r\n\r\nCoordination is performed in the driver and build manager as today, except that phase 3 is optional (through a flag similar to `-s` in gcc). There can be more than one target language.\r\n\r\nThe [implementation overview](https://github.com/python/mypy/wiki/Implementation-Overview) describes four passes, but the data structures used are intermangled and not modular.  Additionally, currently the \"constraint language\" is a hierarchy of Python classes and Python code.\r\n\r\nIn principle the system should be able to work without any Python object passed between phase 2 and 3 (I think that separating 1 and 2 is harder). This modularity will allow using other tools for each phase, and will be useful in case someone wants to plug in efficient constraint-solvers for scalability, or use mypy's constraint solver for portability. It is complementary to a plugin API, and will put less requirements on it.\r\n\r\n(Of course, objects _may_ be passed between 2 and 3 as an optimization, but this is just another \"target language\" which must happen through clear API,and my guesses is that such an optimization is unnecessary).\r\n\r\nWhat do you think?"},"comment":{"url":"https://api.github.com/repos/python/mypy/issues/comments/247874147","html_url":"https://github.com/python/mypy/issues/2150#issuecomment-247874147","issue_url":"https://api.github.com/repos/python/mypy/issues/2150","id":247874147,"user":{"login":"elazarg","id":5108069,"avatar_url":"https://avatars.githubusercontent.com/u/5108069?v=3","gravatar_id":"","url":"https://api.github.com/users/elazarg","html_url":"https://github.com/elazarg","followers_url":"https://api.github.com/users/elazarg/followers","following_url":"https://api.github.com/users/elazarg/following{/other_user}","gists_url":"https://api.github.com/users/elazarg/gists{/gist_id}","starred_url":"https://api.github.com/users/elazarg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/elazarg/subscriptions","organizations_url":"https://api.github.com/users/elazarg/orgs","repos_url":"https://api.github.com/users/elazarg/repos","events_url":"https://api.github.com/users/elazarg/events{/privacy}","received_events_url":"https://api.github.com/users/elazarg/received_events","type":"User","site_admin":false},"created_at":"2016-09-18T20:16:25Z","updated_at":"2016-09-18T20:16:25Z","body":"The first question is whether this architecture is indeed desirable in the first place, ignoring the costs. As you said, @JukkaL undoubtedly had his reasons, but the situation might have changed since 2014. If this architecture is not desirable, then there's nothing more to discuss; the decisions will be documented (if they aren't already), and I will learn something new.\r\n\r\nAssuming the change is desirable, the question becomes that of cost/benefit. I understand the voice of experience says the cost is significantly more than it seems. But we can still discuss strategies for going in that direction in an incremental way, which might be feasible since the current design already use explicit separate passes. I have read Joel's post some years ago; I believe he has a point, and of course I don't suggest reimplementing anything from scratch; if that's necessary for the change, I withdraw my suggestion.\r\n\r\nAt the very least, a decision to move in this direction can justify certain refactoring (yes, I know, don't say anything), be a guide in implementing and reviewing new features (e.g. \"don't entangle these two pieces of data\") and help deciding which parts of the code deserve more documentation.\r\n\r\nAs a related but independent suggestion, I will be nice to have \"assertion passes\" between the phases, to verify (and document) the post-conditions of each pass and pre-conditions of the next, without adding more clutter to the code. Currently breaking something in e.g. the semantic analysis pass, is likely to result in (seemingly unrelated) error message in latter phases. Of course it cannot be avoided, but it can be reduced. After (gradually and slowly) implementing detailed assertion passes, it will be somewhat more straight forward to define a more explicit API between the passes, even if some intermediate state will still be implicit.\r\n\r\nAnother step might be serializing constraints as an optional step. Note that this is _already_ done, in the form of stubgen - after all, a `.pyi` file is a constraint database, although only partial. information. There are two other parts that I can see: the usage constraints, and the rules of the type system. Again, as far as I can see (which is not so far, I admit) everything can be done incrementally, and it will already give the benefit of being able to plug in different solvers. Another step might be implementing deserialization of constraints, which again is already partially implemented in the form of consuming `.pyi` files."}}
{"actor":{"display_login":"elazarg"}}