{"action":"created","issue":{"url":"https://api.github.com/repos/davidhalter/jedi/issues/661","labels_url":"https://api.github.com/repos/davidhalter/jedi/issues/661/labels{/name}","comments_url":"https://api.github.com/repos/davidhalter/jedi/issues/661/comments","events_url":"https://api.github.com/repos/davidhalter/jedi/issues/661/events","html_url":"https://github.com/davidhalter/jedi/pull/661","id":121954042,"number":661,"title":"(Initial) support for pep0484 annotation type hints","user":{"login":"reinhrst","id":1173730,"avatar_url":"https://avatars.githubusercontent.com/u/1173730?v=3","gravatar_id":"","url":"https://api.github.com/users/reinhrst","html_url":"https://github.com/reinhrst","followers_url":"https://api.github.com/users/reinhrst/followers","following_url":"https://api.github.com/users/reinhrst/following{/other_user}","gists_url":"https://api.github.com/users/reinhrst/gists{/gist_id}","starred_url":"https://api.github.com/users/reinhrst/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/reinhrst/subscriptions","organizations_url":"https://api.github.com/users/reinhrst/orgs","repos_url":"https://api.github.com/users/reinhrst/repos","events_url":"https://api.github.com/users/reinhrst/events{/privacy}","received_events_url":"https://api.github.com/users/reinhrst/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-12-14T00:02:48Z","updated_at":"2015-12-24T13:56:42Z","closed_at":"2015-12-20T22:19:19Z","pull_request":{"url":"https://api.github.com/repos/davidhalter/jedi/pulls/661","html_url":"https://github.com/davidhalter/jedi/pull/661","diff_url":"https://github.com/davidhalter/jedi/pull/661.diff","patch_url":"https://github.com/davidhalter/jedi/pull/661.patch"},"body":"Per request PR to linter branch for #170 .\r\n\r\nHandled the comments on https://github.com/davidhalter/jedi/pull/659 , new/more comments are always welcome!\r\n\r\nIt should now recognise simple function parameter and return type annotations (this means: single built in or custom classes, including forward referencing)."},"comment":{"url":"https://api.github.com/repos/davidhalter/jedi/issues/comments/167115364","html_url":"https://github.com/davidhalter/jedi/pull/661#issuecomment-167115364","issue_url":"https://api.github.com/repos/davidhalter/jedi/issues/661","id":167115364,"user":{"login":"reinhrst","id":1173730,"avatar_url":"https://avatars.githubusercontent.com/u/1173730?v=3","gravatar_id":"","url":"https://api.github.com/users/reinhrst","html_url":"https://github.com/reinhrst","followers_url":"https://api.github.com/users/reinhrst/followers","following_url":"https://api.github.com/users/reinhrst/following{/other_user}","gists_url":"https://api.github.com/users/reinhrst/gists{/gist_id}","starred_url":"https://api.github.com/users/reinhrst/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/reinhrst/subscriptions","organizations_url":"https://api.github.com/users/reinhrst/orgs","repos_url":"https://api.github.com/users/reinhrst/repos","events_url":"https://api.github.com/users/reinhrst/events{/privacy}","received_events_url":"https://api.github.com/users/reinhrst/received_events","type":"User","site_admin":false},"created_at":"2015-12-24T13:56:42Z","updated_at":"2015-12-24T13:56:42Z","body":"OK, looked around a bit, and it looks like the `asyncore` module does actually provide the building blocks one needs without having to deal with async sockets themselves in different OSses. Building a small http server on top should not be to hard (and probably already exists somewhere out there on the internet).\r\n\r\nA question might actually be why one would care for an async server at all. Since jedi is 100% CPU bound (except getting the python files from disk, but I don't think we have to take that into account), what would the advantage of an async server be? I guess though that first we would have to consider what exactly the server should do, and how this should be done.\r\n\r\nIn my case the main goal in getting this to work, is to get jedi to be independent from whatever version of python I compiled into vim (and whatever virtualenv was active when I started vim). For this, all I require is that jedi runs in its own process I think (and that I can possibly start multiple jedi's if I'm editing 2 files in one vim instance that run on different versions of python / different virtualenvs --- obviously this raises all kind on new questions on how vim knows what python/virtualenv should be used for a particular file, but let's skip that for now).\r\n\r\nUsing a HTTP server on jedi introduces 2 layers of complexity that I'm not sure are needed at all:\r\n- HTTP uses a new connection per request. This means (in addition to minor extra overhead, both in CPU and in code complexity) that in theory someone could try connecting two different clients to the same server. Is this something we would want to support? E.g. if I'm sure that all connections are from one client, I know I can ignore an older request for completion when a new one comes in (I think). With multiple clients, no such assumption can be made. In addition, jedi-server has no way of knowing when it should shut down (if the client crashes and forgets to send a kill command). I recon it could decide to shut down after not seeing any requests for 10 minutes or so assuming the client will start a new server  if it finds the old one dead, but this means that all cache is invalidated as soon as you take a small coffee break. Using a persistent connection, the OS is responsible for figuring out if the other side died, and jedi-server can just kill itself if the connection drops (or if, at startup, no connection was made within x seconds). Finally, HTTP itself introduces quite some code.\r\n- Using sockets does bring in a question of security. If no extra security measures are taken, I think that from a security perspective it should be assumed that anyone being able to connect to the socket, can read any file that the user the jedi-server is running under (perhaps not exactly in the current codebase, but you don't want to consider these security implications every time something is added to jedi). If jedi-server uses an TCP/IP socket on 127.0.0.1, any process on localhost (on normal desktop OSses) can access these. Alternatively a unix/NT-socket can be used, which one could make writable only to the correct user, which would solve most of these issues, but probably need extensive testing on different OSses (and I for one don't have a windows machine here). As a security precaution each request could be accompanied by a secret that is shared between client and server; not hard but certainly extra complexity. As a final alternative it's also an idea to say that the security issue is one we're willing to take (which seems to be what iPython notebooks do, except that there you also get write-permissions....).\r\n\r\nThe simplest solution in my eyes would be to just communicate to jedi-server over stdin/stdout (I'm not 100% sure that vim can do this, start a subprocess, communicate to it while being responsive to user interaction; I think this was one of the reasons why REPLs could be implemented in emacs but not in vim, but I'm not sure).  Even if in some situations a full HTTP-interface would be needed, I think it would still make sense to also offer a much simpler interface over stdin.\r\n\r\nSo I think that step one would be to get a good idea of use cases. I can reason very well out of my own situation, not knowing which other situations jedi is being used in."}}