Jedi Development¶
Note
This documentation is for Jedi developers who want to improve Jedi itself, but have no idea how Jedi works. If you want to use Jedi for your IDE, look at the plugin api.
Introduction¶
This page tries to address the fundamental demand for documentation of the Jedi interals. Understanding a dynamic language is a complex task. Especially because type inference in Python can be a very recursive task. Therefore Jedi couldn’t get rid of complexity. I know that simple is better than complex, but unfortunately it sometimes requires complex solutions to understand complex systems.
Since most of the Jedi internals have been written by me (David Halter), this introduction will be written mostly by me, because no one else understands to the same level how Jedi works. Actually this is also the reason for exactly this part of the documentation. To make multiple people able to edit the Jedi core.
In five chapters I’m trying to describe the internals of Jedi:
Note
Testing is not documented here, you’ll find that right here.
The Jedi Core¶
The core of Jedi consists of three parts:
Most people are probably interested in code evaluation,
because that’s where all the magic happens. I need to introduce the parser first, because jedi.evaluate
uses it extensively.
Parser (parser/__init__.py)¶
The Parser
tries to convert the available Python code in an easy to read
format, something like an abstract syntax tree. The classes who represent this
tree, are sitting in the jedi.parser.tree
module.
The Python module tokenize
is a very important part in the Parser
,
because it splits the code into different words (tokens). Sometimes it looks a
bit messy. Sorry for that! You might ask now: “Why didn’t you use the ast
module for this? Well, ast
does a very good job understanding proper Python
code, but fails to work as soon as there’s a single line of broken code.
There’s one important optimization that needs to be known: Statements are not
being parsed completely. Statement
is just a representation of the tokens
within the statement. This lowers memory usage and cpu time and reduces the
complexity of the Parser
(there’s another parser sitting inside
Statement
, which produces Array
and Call
).
Parser Representation (parser/representation.py)¶
Class inheritance diagram:
Evaluation of python code (evaluate/__init__.py)¶
Evaluation of Python code in Jedi is based on three assumptions:
- The code uses as least side effects as possible. Jedi understands certain list/tuple/set modifications, but there’s no guarantee that Jedi detects everything (list.append in different modules for example).
- No magic is being used:
- metaclasses
setattr()
/__import__()
- writing to
globals()
,locals()
,object.__dict__
- The programmer is not a total dick, e.g. like this :-)
The actual algorithm is based on a principle called lazy evaluation. If you
don’t know about it, google it. That said, the typical entry point for static
analysis is calling eval_statement
. There’s separate logic for
autocompletion in the API, the evaluator is all about evaluating an expression.
Now you need to understand what follows after eval_statement
. Let’s
make an example:
import datetime
datetime.date.toda# <-- cursor here
First of all, this module doesn’t care about completion. It really just cares
about datetime.date
. At the end of the procedure eval_statement
will
return the date
class.
To visualize this (simplified):
Evaluator.eval_statement
doesn’t do much, because there’s no assignment.Evaluator.eval_element
cares for resolving the dotted pathEvaluator.find_types
searches for global definitions of datetime, which it finds in the definition of an import, by scanning the syntax tree.- Using the import logic, the datetime module is found.
- Now
find_types
is called again byeval_element
to finddate
inside the datetime module.
Now what would happen if we wanted datetime.date.foo.bar
? Two more
calls to find_types
. However the second call would be ignored, because the
first one would return nothing (there’s no foo attribute in date
).
What if the import would contain another ExprStmt
like this:
from foo import bar
Date = bar.baz
Well... You get it. Just another eval_statement
recursion. It’s really
easy. Python can obviously get way more complicated then this. To understand
tuple assignments, list comprehensions and everything else, a lot more code had
to be written.
Jedi has been tested very well, so you can just start modifying code. It’s best to write your own test first for your “new” feature. Don’t be scared of breaking stuff. As long as the tests pass, you’re most likely to be fine.
I need to mention now that lazy evaluation is really good because it only evaluates what needs to be evaluated. All the statements and modules that are not used are just being ignored.
Evaluation Representation (evaluate/representation.py)¶
Like described in the jedi.parser.tree
module,
there’s a need for an ast like module to represent the states of parsed
modules.
But now there are also structures in Python that need a little bit more than
that. An Instance
for example is only a Class
before it is
instantiated. This class represents these cases.
So, why is there also a Class
class here? Well, there are decorators and
they change classes in Python 3.
Representation modules also define “magic methods”. Those methods look like
py__foo__
and are typically mappable to the Python equivalents __call__
and others. Here’s a list:
Method | Description |
py__call__(evaluator, params: Array) | On callable objects, returns types. |
py__bool__() | Returns True/False/None; None means that there’s no certainty. |
py__bases__(evaluator) | Returns a list of base classes. |
py__mro__(evaluator) | Returns a list of classes (the mro). |
py__getattribute__(evaluator, name) | Returns a list of attribute values. The name can be str or Name. |
Name resolution (evaluate/finder.py)¶
Searching for names with given scope and name. This is very central in Jedi and
Python. The name resolution is quite complicated with descripter,
__getattribute__
, __getattr__
, global
, etc.
Flow checks¶
Flow checks are not really mature. There’s only a check for isinstance
. It
would check whether a flow has the form of if isinstance(a, type_or_tuple)
.
Unfortunately every other thing is being ignored (e.g. a == ‘’ would be easy to
check for -> a is a string). There’s big potential in these checks.
API (api.py and api_classes.py)¶
The API has been designed to be as easy to use as possible. The API documentation can be found here. The API itself contains little code that needs to be mentioned here. Generally I’m trying to be conservative with the API. I’d rather not add new API features if they are not necessary, because it’s much harder to deprecate stuff than to add it later.
Core Extensions¶
Core Extensions is a summary of the following topics:
These topics are very important to understand what Jedi additionally does, but they could be removed from Jedi and Jedi would still work. But slower and without some features.
Iterables & Dynamic Arrays (evaluate/iterable.py)¶
To understand Python on a deeper level, Jedi needs to understand some of the dynamic features of Python, however this probably the most complicated part:
Contains all classes and functions to deal with lists, dicts, generators and iterators in general.
Array modifications¶
If the content of an array (set
/list
) is requested somewhere, the
current module will be checked for appearances of arr.append
,
arr.insert
, etc. If the arr
name points to an actual array, the
content will be added
This can be really cpu intensive, as you can imagine. Because Jedi has to
follow every append
and check wheter it’s the right array. However this
works pretty good, because in slow cases, the recursion detector and other
settings will stop this process.
It is important to note that:
- Array modfications work only in the current module.
- Jedi only checks Array additions;
list.pop
, etc are ignored.
Parameter completion (evaluate/dynamic.py)¶
One of the really important features of Jedi is to have an option to understand code like this:
def foo(bar):
bar. # completion here
foo(1)
There’s no doubt wheter bar is an int
or not, but if there’s also a call
like foo('str')
, what would happen? Well, we’ll just show both. Because
that’s what a human would expect.
It works as follows:
- Jedi sees a param
- search for function calls named
foo
- execute these calls and check the input. This work with a
ParamListener
.
Fast Parser (parser/fast.py)¶
Basically a parser that is faster, because it tries to parse only parts and if anything changes, it only reparses the changed parts. But because it’s not finished (and still not working as I want), I won’t document it any further.
Docstrings (evaluate/docstrings.py)¶
Docstrings are another source of information for functions and classes.
jedi.evaluate.dynamic
tries to find all executions of functions, while
the docstring parsing is much easier. There are two different types of
docstrings that Jedi understands:
For example, the sphinx annotation :type foo: str
clearly states that the
type of foo
is str
.
As an addition to parameter searching, this module also provides return annotations.
Refactoring (evaluate/refactoring.py)¶
Introduce some basic refactoring functions to Jedi. This module is still in a very early development stage and needs much testing and improvement.
Warning
I won’t do too much here, but if anyone wants to step in, please do. Refactoring is none of my priorities
It uses the Jedi API and supports currently the following functions (sometimes bug-prone):
- rename
- extract variable
- inline variable
Imports & Modules¶
Compiled Modules (evaluate/compiled.py)¶
Imitate the parser representation.
Imports (evaluate/imports.py)¶
jedi.evaluate.imports
is here to resolve import statements and return
the modules/classes/functions/whatever, which they stand for. However there’s
not any actual importing done. This module is about finding modules in the
filesystem. This can be quite tricky sometimes, because Python imports are not
always that simple.
This module uses imp for python up to 3.2 and importlib for python 3.3 on; the correct implementation is delegated to _compatibility.
This module also supports import autocompletion, which means to complete
statements like from datetim
(curser at the end would return datetime
).
Caching & Recursions¶
Caching (cache.py)¶
This caching is very important for speed and memory optimizations. There’s nothing really spectacular, just some decorators. The following cache types are available:
- module caching (load_parser and save_parser), which uses pickle and is
really important to assure low load times of modules like
numpy
. time_cache
can be used to cache something for just a limited time span, which can be useful if there’s user interaction and the user cannot react faster than a certain time.
This module is one of the reasons why Jedi is not thread-safe. As you can see there are global variables, which are holding the cache information. Some of these variables are being cleaned after every API usage.
Recursions (recursion.py)¶
Recursions are the recipe of Jedi to conquer Python code. However, someone must stop recursions going mad. Some settings are here to make Jedi stop at the right time. You can read more about them here.
Next to jedi.evaluate.cache
this module also makes Jedi not
thread-safe. Why? execution_recursion_decorator
uses class variables to
count the function calls.
Helper Modules¶
Most other modules are not really central to how Jedi works. They all contain relevant code, but you if you understand the modules above, you pretty much understand Jedi.
Python 2/3 compatibility (_compatibility.py)¶
To ensure compatibility from Python 2.6
- 3.3
, a module has been
created. Clearly there is huge need to use conforming syntax.