bundle/jedi-vim/pythonx/jedi/docs/docs/features.rst
.. include:: ../global.rst
Jedi's main API calls and features are:
.Script.complete; It's also possible to get it
working in :ref:your REPL (IPython, etc.) <repl-completion>.Script.goto and :meth:.Script.infer.Script.get_names and :meth:.Script.get_syntax_errors.Script.rename, :meth:.Script.inline,
:meth:.Script.extract_variable and :meth:.Script.extract_function.Script.search and :meth:.Project.searchvirtualenv/venv supporttype hinting <type-hinting>,|jedi| supports many of the widely used Python features:
*args / **kwargs__call__, __iter__, __next__, __get__,
__getitem__, __init__list.append(), set.add(), list.extend(), etc.getattr() / __getattr__ / __getattribute__sys.path modificationsisinstance checks for if/while/assertpkgutil, pkg_resources and PEP420 namespaces)In general Jedi's limit is quite high, but for very big projects or very complex code, sometimes Jedi intentionally stops type inference, to avoid hanging for a long time.
Additionally there are some Python patterns Jedi does not support. This is intentional and below should be a complete list:
setattr(), __import__()globals(), locals(), object.__dict__Performance Issues
Importing ``numpy`` can be quite slow sometimes, as well as loading the
builtins the first time. If you want to speed things up, you could preload
libriaries in |jedi|, with :func:`.preload_module`. However, once loaded, this
should not be a problem anymore. The same is true for huge modules like
``PySide``, ``wx``, ``tensorflow``, ``pandas``, etc.
Jedi does not have a very good cache layer. This is probably the biggest and
only architectural `issue <https://github.com/davidhalter/jedi/issues/1059>`_ in
Jedi. Unfortunately it is not easy to change that. Dave Halter is thinking
about rewriting Jedi in Rust, but it has taken Jedi more than 8 years to reach
version 1.0, a rewrite will probably also take years.
Security
--------
For :class:`.Script`
Security is an important topic for |jedi|. By default, no code is executed
within Jedi. As long as you write pure Python, everything is inferred
statically. If you enable load_unsafe_extensions=True for your
:class:.Project and you use builtin modules (c_builtin) Jedi will execute
those modules. If you don't trust a code base, please do not enable that
option. It might lead to arbitrary code execution.
For :class:.Interpreter
If you want security for :class:`.Interpreter`, ``do not`` use it. Jedi does
execute properties and in general is not very careful to avoid code execution.
This is intentional: Most people trust the code bases they have imported,
because at that point a malicious code base would have had code execution
already.