Show More
@@ -1,104 +1,104 b'' | |||
|
1 | 1 | How IPython works |
|
2 | 2 | ================= |
|
3 | 3 | |
|
4 | 4 | Terminal IPython |
|
5 | 5 | ---------------- |
|
6 | 6 | |
|
7 | 7 | When you type ``ipython``, you get the original IPython interface, running in |
|
8 | 8 | the terminal. It does something like this:: |
|
9 | 9 | |
|
10 | 10 | while True: |
|
11 | 11 | code = input(">>> ") |
|
12 | 12 | exec(code) |
|
13 | 13 | |
|
14 | 14 | Of course, it's much more complicated, because it has to deal with multi-line |
|
15 | 15 | code, tab completion using :mod:`readline`, magic commands, and so on. But the |
|
16 | 16 | model is like that: prompt the user for some code, and when they've entered it, |
|
17 | 17 | exec it in the same process. This model is often called a REPL, or |
|
18 | 18 | Read-Eval-Print-Loop. |
|
19 | 19 | |
|
20 | 20 | The IPython Kernel |
|
21 | 21 | ------------------ |
|
22 | 22 | |
|
23 | 23 | All the other interfaces—the Notebook, the Qt console, ``ipython console`` in |
|
24 | 24 | the terminal, and third party interfaces—use the IPython Kernel. This is a |
|
25 | 25 | separate process which is responsible for running user code, and things like |
|
26 | 26 | computing possible completions. Frontends communicate with it using JSON |
|
27 | 27 | messages sent over `ZeroMQ <http://zeromq.org/>`_ sockets; the protocol they use is described in |
|
28 | 28 | :doc:`messaging`. |
|
29 | 29 | |
|
30 | 30 | The core execution machinery for the kernel is shared with terminal IPython: |
|
31 | 31 | |
|
32 | 32 | .. image:: figs/ipy_kernel_and_terminal.png |
|
33 | 33 | |
|
34 | 34 | A kernel process can be connected to more than one frontend simultaneously. In |
|
35 | 35 | this case, the different frontends will have access to the same variables. |
|
36 | 36 | |
|
37 | 37 | .. TODO: Diagram illustrating this? |
|
38 | 38 | |
|
39 | 39 | This design was intended to allow easy development of different frontends based |
|
40 | 40 | on the same kernel, but it also made it possible to support new languages in the |
|
41 | 41 | same frontends, by developing kernels in those languages, and we are refining |
|
42 | 42 | IPython to make that more practical. |
|
43 | 43 | |
|
44 | 44 | Today, there are two ways to develop a kernel for another language. Wrapper |
|
45 | 45 | kernels reuse the communications machinery from IPython, and implement only the |
|
46 | 46 | core execution part. Native kernels implement execution and communications in |
|
47 | 47 | the target language: |
|
48 | 48 | |
|
49 | 49 | .. image:: figs/other_kernels.png |
|
50 | 50 | |
|
51 | 51 | Wrapper kernels are easier to write quickly for languages that have good Python |
|
52 | wrappers, like `Oct2Py <http://blink1073.github.io/oct2py/>`_ for Octave, or | |
|
52 | wrappers, like `octave_kernel <https://pypi.python.org/pypi/octave_kernel>`_, or | |
|
53 | 53 | languages where it's impractical to implement the communications machinery, like |
|
54 | 54 | `bash_kernel <https://pypi.python.org/pypi/bash_kernel>`_. Native kernels are |
|
55 | 55 | likely to be better maintained by the community using them, like |
|
56 | 56 | `IJulia <https://github.com/JuliaLang/IJulia.jl>`_ or `IHaskell <https://github.com/gibiansky/IHaskell>`_. |
|
57 | 57 | |
|
58 | 58 | .. seealso:: |
|
59 | 59 | |
|
60 | 60 | :doc:`kernels` |
|
61 | 61 | |
|
62 | 62 | :doc:`wrapperkernels` |
|
63 | 63 | |
|
64 | 64 | Notebooks |
|
65 | 65 | --------- |
|
66 | 66 | |
|
67 | 67 | The Notebook frontend does something extra. In addition to running your code, it |
|
68 | 68 | stores code and output, together with markdown notes, in an editable document |
|
69 | 69 | called a notebook. When you save it, this is sent from your browser to the |
|
70 | 70 | notebook server, which saves it on disk as a JSON file with a ``.ipynb`` |
|
71 | 71 | extension. |
|
72 | 72 | |
|
73 | 73 | .. image:: figs/notebook_components.png |
|
74 | 74 | |
|
75 | 75 | The notebook server, not the kernel, is responsible for saving and loading |
|
76 | 76 | notebooks, so you can edit notebooks even if you don't have the kernel for that |
|
77 | 77 | language—you just won't be able to run code. The kernel doesn't know anything |
|
78 | 78 | about the notebook document: it just gets sent cells of code to execute when the |
|
79 | 79 | user runs them. |
|
80 | 80 | |
|
81 | 81 | Exporting to other formats |
|
82 | 82 | `````````````````````````` |
|
83 | 83 | |
|
84 | 84 | The Nbconvert tool in IPython converts notebook files to other formats, such as |
|
85 | 85 | HTML, LaTeX, or reStructuredText. This conversion goes through a series of steps: |
|
86 | 86 | |
|
87 | 87 | .. image:: figs/nbconvert.png |
|
88 | 88 | |
|
89 | 89 | 1. Preprocessors modify the notebook in memory. E.g. ExecutePreprocessor runs |
|
90 | 90 | the code in the notebook and updates the output. |
|
91 | 91 | 2. An exporter converts the notebook to another file format. Most of the |
|
92 | 92 | exporters use templates for this. |
|
93 | 93 | 3. Postprocessors work on the file produced by exporting. |
|
94 | 94 | |
|
95 | 95 | The `nbviewer <http://nbviewer.ipython.org/>`_ website uses nbconvert with the |
|
96 | 96 | HTML exporter. When you give it a URL, it fetches the notebook from that URL, |
|
97 | 97 | converts it to HTML, and serves that HTML to you. |
|
98 | 98 | |
|
99 | 99 | IPython.parallel |
|
100 | 100 | ---------------- |
|
101 | 101 | |
|
102 | 102 | IPython also includes a parallel computing framework, ``IPython.parallel``. This |
|
103 | 103 | allows you to control many individual engines, which are an extended version of |
|
104 | 104 | the IPython kernel described above. For more details, see :doc:`/parallel/index`. |
General Comments 0
You need to be logged in to leave comments.
Login now