bfredl
bfredl
commented over there :]
In general I agree with this, but I would suggest for this PR to only drop obsolete python version support, and adding annotations to existing methods where we find that...
don't be too afraid to break 2.7 if there is clear benefit. pynvim 0.5 can be py3.5+ only if we want to.
No worries, we are indulging hacktoberfest as an allowed fun (temporarily).
Dropping support for python 2 on master is fine. We could create a separate maintenance branch for bug-fixes only on top of 0.4.0 (or whatever the last python 2 version)
Same thing there, python 3.4 can stay on 0.4.0/maintenance branch (if anyone still uses it). Lets move master forward.
A constraint to consider might be making it convenient for plugins to use greenlets to handle messaging to other sources. Right now in my ipython plugin I do this to...
Yeah, I think it would be cleaner API if one doesn't have to use two different `nvim` objects. A possible interface could be: ``` nvim.eval('1') ==> yield from this greenlet...
Updated, now it has simpler `vim.session.poll_fd(fd, on_readable=callback)` api, and a greenlet is not automatically spawned.
Updated. Goes back to spawn a greenlet per default, to behave like a an ordinary (async) neovim command handler or `async_call` callback (i e api calls can be done in...