mirror of
https://github.com/davidhalter/jedi.git
synced 2026-05-19 23:09:43 +08:00
reformat feature documentation
This commit is contained in:
+16
-15
@@ -64,8 +64,8 @@ Caveats
|
|||||||
**Malformed Syntax**
|
**Malformed Syntax**
|
||||||
|
|
||||||
Syntax errors and other strange stuff may lead to undefined behaviour of the
|
Syntax errors and other strange stuff may lead to undefined behaviour of the
|
||||||
completion. |jedi| is **NOT** a Python compiler, that tries to correct you. It is
|
completion. |jedi| is **NOT** a Python compiler, that tries to correct you. It
|
||||||
a tool that wants to help you. But **YOU** have to know Python, not |jedi|.
|
is a tool that wants to help you. But **YOU** have to know Python, not |jedi|.
|
||||||
|
|
||||||
**Legacy Python 2 Features**
|
**Legacy Python 2 Features**
|
||||||
|
|
||||||
@@ -78,19 +78,20 @@ older Python 2 features have been left out:
|
|||||||
|
|
||||||
**Slow Performance**
|
**Slow Performance**
|
||||||
|
|
||||||
Importing ``numpy`` can be quite slow sometimes, as well as loading the builtins
|
Importing ``numpy`` can be quite slow sometimes, as well as loading the
|
||||||
the first time. If you want to speed things up, you could write import hooks in
|
builtins the first time. If you want to speed things up, you could write import
|
||||||
|jedi|, which preload stuff. However, once loaded, this is not a problem anymore.
|
hooks in |jedi|, which preload stuff. However, once loaded, this is not a
|
||||||
The same is true for huge modules like ``PySide``, ``wx``, etc.
|
problem anymore. The same is true for huge modules like ``PySide``, ``wx``,
|
||||||
|
etc.
|
||||||
|
|
||||||
**Security**
|
**Security**
|
||||||
|
|
||||||
Security is an important issue for |jedi|. Therefore no Python code is executed.
|
Security is an important issue for |jedi|. Therefore no Python code is
|
||||||
As long as you write pure python, everything is evaluated statically. But: If
|
executed. As long as you write pure python, everything is evaluated
|
||||||
you use builtin modules (``c_builtin``) there is no other option than to execute
|
statically. But: If you use builtin modules (``c_builtin``) there is no other
|
||||||
those modules. However: Execute isn't that critical (as e.g. in pythoncomplete,
|
option than to execute those modules. However: Execute isn't that critical (as
|
||||||
which used to execute *every* import!), because it means one import and no more.
|
e.g. in pythoncomplete, which used to execute *every* import!), because it
|
||||||
So basically the only dangerous thing is using the import itself. If your
|
means one import and no more. So basically the only dangerous thing is using
|
||||||
``c_builtin`` uses some strange initializations, it might be dangerous. But if
|
the import itself. If your ``c_builtin`` uses some strange initializations, it
|
||||||
it does you're screwed anyways, because eventualy you're going to execute your
|
might be dangerous. But if it does you're screwed anyways, because eventualy
|
||||||
code, which executes the import.
|
you're going to execute your code, which executes the import.
|
||||||
|
|||||||
Reference in New Issue
Block a user