-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose asyncio to python3 rplugins, removing python3.3 support #294
Conversation
Thanks. I want to use the feature for deoplete. |
d3ef45f
to
27c36af
Compare
Sorry for the delay, this works so far:
But it is not very convenient. We probably want |
Thank you! I will check it. |
It is conflicting. |
@bfredl Ping. |
27c36af
to
ab3b839
Compare
Sorry for the delay. I will add some documentation also tomorrow maybe, then we can merge this. Wrappers can be a follow-up PR. I e things like #72 can be implement much simpler, no need to traverse layers, can just implement thin wrapper directly in nvim module. |
Thanks. I will add support the feature in deoplete later. |
@bfredl I want to write input to sub process in asyncio loop. |
d1c9c31
to
55f751d
Compare
@Shougo Yes, in the example above, in |
Disallow python3.3 python2.7 is unchanged (pyuv is still preferred; loop not exposed)
In this release support of python3.3 is dropped. Henceforth we want python3 rplugins to be able to assume the usage of asyncio, so they can use the asyncio event loop and libraries that build on it. Furthermore, a close() method is added on nvim session objects. When used as a library for externally connecting to a nvim instance (i e not rplugins), it is recommended to call the close() method on the session object when it is not needed anymore. Alternatively, sessions can be used as a context manager: with neovim.attach('socket', path=thepath) as nvim: # do stuff with nvim session in this block: print(nvim.funcs.getpid()) print(nvim.current.line) This will close the session automatically. Changes since 0.2.1: * 2689ddc add tests for plugin decorators #298 * 63f257f allow library users to properly cleanup the event loop #303 * 59c184f expose the asyncio event loop as nvim.loop (python 3.4+ only) #294
Thank you. create = self.nvim.loop.subprocess_exec(partial(MySubprocess,self),
sys.executable, '-c', code,
stdin=None, stderr=None) I think if stdin is None, the input feature will be disabled. |
@bfredl Ping. |
And I think the feature is not supported in Windows. |
The test is works for me. Hm. |
@bfredl No problem. deoplete asyncio works for me. |
Currently, handling events beyond nvim itself is very limited, the only way additional sources can be added is with separate threads invoking
nvim.async_call
. A problem is that the implemenation is dynamic between two event loops: asyncio and pyuv, so plugins can't use them.The plan is to require asyncio on python3 so we can expose asyncio event loop to python3 rplugins. Python3.3 is hereby unsupported. Python2.7 rplugins is considered legacy: existing py2.7 rplugins remain supported for now, but new features might not be available (python2 via vim
:python
interface remain supported of course)I know issues on windows has held up this change in the past (#243). We might need to change the asyncio backend on windows. IIRC there is even a libuv based backend, but I don't know it's status. I will look into this tomorrow.
I will make example and test this with subprocess communication, using msgpack to comminucate with a python helper process. I know deoplete wants to use the feature for multiprocess. Ping @Shougo