Cannot autocomplete members of variables initialized with 'await'
See original GitHub issueIssue
Members of variables initialized with await ...
cannot be autocompleted.
Steps to reproduce
Minimal example should be something like
async def f() -> str:
return 'test'
async def main():
# a = f() # works, but is wrong. jedi autocompletes as if f() was not async, though.
a = await f()
a.
No completion happens after a.
. In fact, after completion fails, erasing await
does NOT make it work again.
Output of “:verbose JediDebugInfo”
Jedi-vim debug information
Using Python version: 3
- sys.version:
3.6.1 (default, Apr 27 2017, 12:16:19), [GCC 5.4.0]
- site module:
/usr/lib64/python3.6/site.py
Jedi path:/home/tarcisioe/.configmanager/files/vim/plugged/jedi-vim/jedi/jedi/__init__.py
- version: 0.10.2
- sys_path:
/home/tarcisioe/.configmanager/files/vim/plugged/jedi-vim
/usr/lib64/python36.zip
/usr/lib64/python3.6
/usr/lib64/python3.6/lib-dynload
/home/tarcisioe/.local/lib64/python3.6/site-packages
/usr/lib64/python3.6/site-packages
_vim_path_
- jedi-vim git version: a2cf229
- jedi git submodule status: 5427b02712828b2875d35b5ee1c8b5e58f820537 jedi (v0.10.2)
Settings
g:jedi#force_py_version = 3 (default: 'auto')
g:jedi#auto_vim_configuration = 0 (default: 1)
omnifunc=jedi#completions
Last set from ~/.configmanager/files/vim/plugged/jedi-vim/after/ftplugin/python/jedi.vim
completeopt=menu
Last set from ~/.configmanager/files/vim/init.vim
:version
NVIM v0.2.0
Build type: RelWithDebInfo
Compilation: /usr/bin/x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fomit-frame-pointer -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/config -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/src/nvim/auto -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/include
Compiled by portage@jinx
Optional features included (+) or not (-): +acl +iconv +jemalloc +tui
For differences from Vim, see :help vim-differences
system vimrc file: "/etc/vim/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
:messages
W391: blank line at end of file
E999: SyntaxError: invalid syntax
E999: SyntaxError: invalid syntax
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:6 (4 by maintainers)
Top Results From Across the Web
No autocomplete/intellisense for new variables created in ...
Define an async function. Define some variables in the function. Try to use them below but no autocomplete for them. And the variables...
Read more >Async / Await: Cannot access variable before initialization ...
The problem is in the function foo(). bar is already a function and you're trying to assign to it while calling it, which...
Read more >Dynamic behavior in Svelte: working with variables and props
In this article we'll be using variables and props to make our app dynamic, ... which when omitted will be initialized to an...
Read more >Uncaught TypeError: Cannot read property of null - iDiallo
All this means is that you are trying to access a property of an object that is undefined. These usually happens when we...
Read more >async/await Visual Studio autocomplete
If my understanding is correct you have to await an async method and you can only use await in an async method. Why...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I see. Would you think it’s too hard to implement at least a basic support for following the return types? I may be able to spend some time at it and attempt a PR.
Async/Await support is ready in jedi. Coming with the next release. Please open a new issue if it doesn’t work with 0.12.0.