VimPlug/jedi-fork
1
0
Fork 0
forked from VimPlug/jedi
Code Pull Requests Activity

Development doc fixes

Browse Source
This commit is contained in:
Danilo Bargen
2013-02-05 11:31:05 +01:00
parent 4e6eff5688
commit a0f07c90e8
3 changed files with 22 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/docs/development.rst
View File

@@ -5,8 +5,8 @@ Jedi Development
.. currentmodule:: jedi
.. note:: This documentation is for Jedi developers, who want to improve Jedi
itself, but have just no idea how Jedi works. If you want to use Jedi for
.. 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 <plugin-api.html>`_.
@@ -17,13 +17,13 @@ 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 requires sometimes complex solutions to understand 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 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.
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|:
@@ -46,8 +46,8 @@ The core of Jedi consists of three parts:
- :ref:`API <dev-api>`
Most people are probably interested in :ref:`code evaluation <evaluate>`,
because that's where all the magic happens. I need to introduce the
:ref:`parser <parsing>` first, because evaluate uses it extensively.
because that's where all the magic happens. I need to introduce the :ref:`parser
<parsing>` first, because :mod:`evaluate` uses it extensively.
.. _parsing:
@@ -68,11 +68,11 @@ Evaluation of python code (evaluate.py)
API (api.py and api_classes.py)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The API has been designed to be as usable as possible. The API documentation
can be found `here <plugin-api.html>`_. 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.
The API has been designed to be as easy to use as possible. The API
documentation can be found `here <plugin-api.html>`_. 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.