Show More
@@ -1,260 +1,261 b'' | |||
|
1 | 1 | |
|
2 | 2 | |
|
3 | 3 | .. _`nbconvert script`: |
|
4 | 4 | |
|
5 | 5 | Converting notebooks to other formats |
|
6 | 6 | ===================================== |
|
7 | 7 | |
|
8 | 8 | Newly added in the 1.0 release of IPython is the ``nbconvert`` tool, which |
|
9 | 9 | allows you to convert an ``.ipynb`` notebook document file into various static |
|
10 | 10 | formats. |
|
11 | 11 | |
|
12 | 12 | Currently, ``nbconvert`` is provided as a command line tool, run as a script |
|
13 | 13 | using IPython. In the future, a direct export capability from within the |
|
14 | 14 | IPython Notebook web app is planned. |
|
15 | 15 | |
|
16 | 16 | The command-line syntax to run the ``nbconvert`` script is:: |
|
17 | 17 | |
|
18 | 18 | $ ipython nbconvert --format=FORMAT notebook.ipynb |
|
19 | 19 | |
|
20 | 20 | This will convert the IPython document file ``notebook.ipynb`` into the output |
|
21 | 21 | format given by the ``FORMAT`` string. |
|
22 | 22 | |
|
23 | 23 | The default output format is HTML, for which the ``--format`` modifier may be |
|
24 | 24 | omitted:: |
|
25 | 25 | |
|
26 | 26 | $ ipython nbconvert notebook.ipynb |
|
27 | 27 | |
|
28 | 28 | The currently supported export formats are the following: |
|
29 | 29 | |
|
30 | 30 | * HTML: |
|
31 | 31 | |
|
32 | 32 | - **full_html**: |
|
33 | 33 | Standard HTML |
|
34 | 34 | |
|
35 | 35 | - **simple_html**: |
|
36 | 36 | Simplified HTML |
|
37 | 37 | |
|
38 | 38 | - **reveal**: |
|
39 | 39 | HTML slideshow presentation for use with the ``reveal.js`` package |
|
40 | 40 | |
|
41 | 41 | * PDF: |
|
42 | 42 | |
|
43 | 43 | - **sphinx_howto**: |
|
44 | 44 | The format for Sphinx_ HOWTOs; similar to an ``article`` in LaTeX |
|
45 | 45 | |
|
46 | 46 | - **sphinx_manual**: |
|
47 | 47 | The format for Sphinx_ manuals; similar to a ``book`` in LaTeX |
|
48 | 48 | |
|
49 | 49 | - **latex**: |
|
50 | 50 | An article formatted completely using LaTeX |
|
51 | 51 | |
|
52 | 52 | * Markup: |
|
53 | 53 | |
|
54 | 54 | - **rst**: |
|
55 | 55 | reStructuredText_ markup |
|
56 | 56 | |
|
57 | 57 | - **markdown**: |
|
58 | 58 | Markdown_ markup |
|
59 | 59 | |
|
60 | 60 | .. _Sphinx: http://sphinx-doc.org/ |
|
61 | 61 | .. _reStructuredText: http://docutils.sourceforge.net/rst.html |
|
62 | .. _Markdown: http://daringfireball.net/projects/markdown/syntax | |
|
62 | 63 | |
|
63 | 64 | * Python: |
|
64 | 65 | |
|
65 | 66 | Comments out all the non-Python code to produce a ``.py`` Python |
|
66 | 67 | script with just the code content. Currently the output includes IPython |
|
67 | 68 | magics, and so can be run with ``ipython``, after changing the extension |
|
68 | 69 | of the script to ``.ipy``. |
|
69 | 70 | |
|
70 | 71 | The files output file created by ``nbconvert`` will have the same base name as |
|
71 | 72 | the notebook and will be placed in the current working directory. Any |
|
72 | 73 | supporting files (graphics, etc) will be placed in a new directory with the |
|
73 | 74 | same base name as the notebook, suffixed with ``_files``:: |
|
74 | 75 | |
|
75 | 76 | $ ipython nbconvert notebook.ipynb |
|
76 | 77 | $ ls |
|
77 | 78 | notebook.ipynb notebook.html notebook_files/ |
|
78 | 79 | |
|
79 | 80 | Each of the options for PDF export produces as an intermediate step a LaTeX |
|
80 | 81 | ``.tex`` file with the same basename as the notebook, as well as individual |
|
81 | 82 | files for each figure, and ``.text`` files with textual output from running |
|
82 | 83 | code cells. |
|
83 | 84 | |
|
84 | 85 | To actually produce the final PDF file, run the following commands:: |
|
85 | 86 | |
|
86 | 87 | $ ipython nbconvert --format=latex notebook.ipynb |
|
87 | 88 | $ pdflatex notebook |
|
88 | 89 | |
|
89 | 90 | This requires a local installation of LaTeX on your machine. |
|
90 | 91 | The output is a PDF file ``notebook.pdf``, also placed inside the |
|
91 | 92 | ``nbconvert_build`` subdirectory. |
|
92 | 93 | |
|
93 | 94 | Alternatively, the output may be sent to standard output with:: |
|
94 | 95 | |
|
95 | 96 | $ ipython nbconvert notebook.ipynb --stdout |
|
96 | 97 | |
|
97 | 98 | Multiple notebooks can be specified from the command line:: |
|
98 | 99 | |
|
99 | 100 | $ ipython nbconvert notebook*.ipynb |
|
100 | 101 | $ ipython nbconvert notebook1.ipynb notebook2.ipynb |
|
101 | 102 | |
|
102 | 103 | or via a list in a configuration file, say ``mycfg.py``, containing the text:: |
|
103 | 104 | |
|
104 | 105 | c = get_config() |
|
105 | 106 | c.NbConvertApp.notebooks = ["notebook1.ipynb", "notebook2.ipynb"] |
|
106 | 107 | |
|
107 | 108 | and using the command:: |
|
108 | 109 | |
|
109 | 110 | $ ipython nbconvert --config mycfg.py |
|
110 | 111 | |
|
111 | 112 | |
|
112 | 113 | Extracting standard Python files from notebooks |
|
113 | 114 | ----------------------------------------------- |
|
114 | 115 | ``.ipynb`` notebook document files are plain text files which store a |
|
115 | 116 | representation in JSON format of the contents of a notebook space. As such, |
|
116 | 117 | they are not valid ``.py`` Python scripts, and so can be neither imported |
|
117 | 118 | directly with ``import`` in Python, nor run directly as a standard Python |
|
118 | 119 | script (though both of these are possible with simple workarounds). |
|
119 | 120 | |
|
120 | 121 | |
|
121 | 122 | To extract the Python code from within a notebook document, the simplest |
|
122 | 123 | method is to use the ``File | Download as | Python (.py)`` menu item; the |
|
123 | 124 | resulting ``.py`` script will be downloaded to your browser's default |
|
124 | 125 | download location. |
|
125 | 126 | |
|
126 | 127 | An alternative is to pass an argument to the IPython Notebook, from the moment |
|
127 | 128 | when it is originally started, specifying that whenever it saves an ``.ipynb`` |
|
128 | 129 | notebook document, it should, at the same time, save the corresponding |
|
129 | 130 | ``.py`` script. To do so, you can execute the following command:: |
|
130 | 131 | |
|
131 | 132 | $ ipython notebook --script |
|
132 | 133 | |
|
133 | 134 | or you can set this option permanently in your configuration file with:: |
|
134 | 135 | |
|
135 | 136 | c = get_config() |
|
136 | 137 | c.NotebookManager.save_script=True |
|
137 | 138 | |
|
138 | 139 | The result is that standard ``.py`` files are also now generated, which |
|
139 | 140 | can be ``%run``, imported from regular IPython sessions or other notebooks, or |
|
140 | 141 | executed at the command line, as usual. Since the raw code you have typed is |
|
141 | 142 | exported, you must avoid using syntax such as IPython magics and other |
|
142 | 143 | IPython-specific extensions to the language for the files to be able to be |
|
143 | 144 | successfully imported. |
|
144 | 145 | .. or you can change the script's extension to ``.ipy`` and run it with:: |
|
145 | 146 | .. |
|
146 | 147 | .. $ ipython script.ipy |
|
147 | 148 | |
|
148 | 149 | In normal Python practice, the standard way to differentiate importable code |
|
149 | 150 | in a Python script from the "executable" part of a script is to use the |
|
150 | 151 | following idiom at the start of the executable part of the code:: |
|
151 | 152 | |
|
152 | 153 | if __name__ == '__main__' |
|
153 | 154 | |
|
154 | 155 | # rest of the code... |
|
155 | 156 | |
|
156 | 157 | Since all cells in the notebook are run as top-level code, you will need to |
|
157 | 158 | similarly protect *all* cells that you do not want executed when other scripts |
|
158 | 159 | try to import your notebook. A convenient shortand for this is to define |
|
159 | 160 | early on:: |
|
160 | 161 | |
|
161 | 162 | script = __name__ == '__main__' |
|
162 | 163 | |
|
163 | 164 | Then in any cell that you need to protect, use:: |
|
164 | 165 | |
|
165 | 166 | if script: |
|
166 | 167 | # rest of the cell... |
|
167 | 168 | |
|
168 | 169 | |
|
169 | 170 | |
|
170 | 171 | .. _notebook_format: |
|
171 | 172 | |
|
172 | 173 | Notebook JSON file format |
|
173 | 174 | ------------------------- |
|
174 | 175 | Notebook documents are JSON files with an ``.ipynb`` extension, formatted |
|
175 | 176 | as legibly as possible with minimal extra indentation and cell content broken |
|
176 | 177 | across lines to make them reasonably friendly to use in version-control |
|
177 | 178 | workflows. You should be very careful if you ever manually edit this JSON |
|
178 | 179 | data, as it is extremely easy to corrupt its internal structure and make the |
|
179 | 180 | file impossible to load. In general, you should consider the notebook as a |
|
180 | 181 | file meant only to be edited by the IPython Notebook app itself, not for |
|
181 | 182 | hand-editing. |
|
182 | 183 | |
|
183 | 184 | .. note:: |
|
184 | 185 | |
|
185 | 186 | Binary data such as figures are also saved directly in the JSON file. |
|
186 | 187 | This provides convenient single-file portability, but means that the |
|
187 | 188 | files can be large; a ``diff`` of binary data is also not very |
|
188 | 189 | meaningful. Since the binary blobs are encoded in a single line, they |
|
189 | 190 | affect only one line of the ``diff`` output, but they are typically very |
|
190 | 191 | long lines. You can use the ``Cell | All Output | Clear`` menu option to |
|
191 | 192 | remove all output from a notebook prior to committing it to version |
|
192 | 193 | control, if this is a concern. |
|
193 | 194 | |
|
194 | 195 | The notebook server can also generate a pure Python version of your notebook, |
|
195 | 196 | using the ``File | Download as`` menu option. The resulting ``.py`` file will |
|
196 | 197 | contain all the code cells from your notebook verbatim, and all Markdown cells |
|
197 | 198 | prepended with a comment marker. The separation between code and Markdown |
|
198 | 199 | cells is indicated with special comments and there is a header indicating the |
|
199 | 200 | format version. All output is removed when exporting to Python. |
|
200 | 201 | |
|
201 | 202 | As an example, consider a simple notebook called ``simple.ipynb`` which |
|
202 | 203 | contains one Markdown cell, with the content ``The simplest notebook.``, one |
|
203 | 204 | code input cell with the content ``print "Hello, IPython!"``, and the |
|
204 | 205 | corresponding output. |
|
205 | 206 | |
|
206 | 207 | The contents of the notebook document ``simple.ipynb`` is the following JSON |
|
207 | 208 | container:: |
|
208 | 209 | |
|
209 | 210 | { |
|
210 | 211 | "metadata": { |
|
211 | 212 | "name": "simple" |
|
212 | 213 | }, |
|
213 | 214 | "nbformat": 3, |
|
214 | 215 | "nbformat_minor": 0, |
|
215 | 216 | "worksheets": [ |
|
216 | 217 | { |
|
217 | 218 | "cells": [ |
|
218 | 219 | { |
|
219 | 220 | "cell_type": "markdown", |
|
220 | 221 | "metadata": {}, |
|
221 | 222 | "source": "The simplest notebook." |
|
222 | 223 | }, |
|
223 | 224 | { |
|
224 | 225 | "cell_type": "code", |
|
225 | 226 | "collapsed": false, |
|
226 | 227 | "input": "print \"Hello, IPython\"", |
|
227 | 228 | "language": "python", |
|
228 | 229 | "metadata": {}, |
|
229 | 230 | "outputs": [ |
|
230 | 231 | { |
|
231 | 232 | "output_type": "stream", |
|
232 | 233 | "stream": "stdout", |
|
233 | 234 | "text": "Hello, IPython\n" |
|
234 | 235 | } |
|
235 | 236 | ], |
|
236 | 237 | "prompt_number": 1 |
|
237 | 238 | } |
|
238 | 239 | ], |
|
239 | 240 | "metadata": {} |
|
240 | 241 | } |
|
241 | 242 | ] |
|
242 | 243 | } |
|
243 | 244 | |
|
244 | 245 | |
|
245 | 246 | The corresponding Python script is:: |
|
246 | 247 | |
|
247 | 248 | # -*- coding: utf-8 -*- |
|
248 | 249 | # <nbformat>3.0</nbformat> |
|
249 | 250 | |
|
250 | 251 | # <markdowncell> |
|
251 | 252 | |
|
252 | 253 | # The simplest notebook. |
|
253 | 254 | |
|
254 | 255 | # <codecell> |
|
255 | 256 | |
|
256 | 257 | print "Hello, IPython" |
|
257 | 258 | |
|
258 | 259 | Note that indeed the output of the code cell, which is present in the JSON |
|
259 | 260 | container, has been removed in the ``.py`` script. |
|
260 | 261 |
@@ -1,564 +1,561 b'' | |||
|
1 | 1 | .. _htmlnotebook: |
|
2 | 2 | |
|
3 | 3 | The IPython Notebook |
|
4 | 4 | ==================== |
|
5 | 5 | |
|
6 | 6 | The IPython Notebook is part of the IPython package, which aims to provide a |
|
7 | 7 | powerful, interactive approach to scientific computation. |
|
8 | 8 | The IPython Notebook extends the previous text-console-based approach, and the |
|
9 | 9 | later Qt console, in a qualitatively new diretion, providing a web-based |
|
10 | 10 | application suitable for capturing the whole scientific computation process. |
|
11 | 11 | |
|
12 | 12 | .. seealso:: |
|
13 | 13 | |
|
14 | 14 | :ref:`Installation requirements <installnotebook>` for the Notebook. |
|
15 | 15 | |
|
16 | 16 | |
|
17 | 17 | .. Basic structure |
|
18 | 18 | .. --------------- |
|
19 | 19 | |
|
20 | 20 | Introduction |
|
21 | 21 | ------------ |
|
22 | 22 | |
|
23 | 23 | The IPython Notebook combines two components: |
|
24 | 24 | |
|
25 | 25 | * **The IPython Notebook web application**: |
|
26 | 26 | |
|
27 | 27 | The *IPython Notebook web app* is a browser-based tool for interactive |
|
28 | 28 | authoring of literate computations, in which explanatory text, |
|
29 | 29 | mathematics, computations and rich media output may be combined. Input |
|
30 | 30 | and output are stored in persistent cells that may be edited in-place. |
|
31 | 31 | |
|
32 | 32 | * **Notebook documents**: |
|
33 | 33 | |
|
34 | 34 | *Notebook documents*, or *notebooks*, are plain text documents which |
|
35 | 35 | record all inputs and outputs of the computations, interspersed with |
|
36 | 36 | text, mathematics and HTML 5 representations of objects, in a literate |
|
37 | 37 | style. |
|
38 | 38 | |
|
39 | 39 | Since the similarity in names can lead to some confusion, in this |
|
40 | 40 | documentation we will use capitalization of the word "notebook" to |
|
41 |
distinguish the |
|
|
41 | distinguish the Notebook app and notebook documents, thinking of the | |
|
42 | 42 | Notebook app as being a proper noun. We will also always refer to the |
|
43 | 43 | "Notebook app" when we are referring to the browser-based interface, |
|
44 | 44 | and usually to "notebook documents", instead of "notebooks", for added |
|
45 | 45 | precision. |
|
46 | 46 | |
|
47 | 47 | We refer to the current state of the computational process taking place in the |
|
48 | 48 | Notebook app, i.e. the (numbered) sequence of input and output cells, as the |
|
49 | 49 | *notebook space*. Notebook documents provide an *exact*, *one-to-one* record |
|
50 | 50 | of all the content in the notebook space, as a plain text file in JSON format. |
|
51 | 51 | The Notebook app automatically saves, at certain intervals, the contents of |
|
52 | 52 | the notebook space to a notebook document stored on disk, with the same name |
|
53 | 53 | as the title of the notebook space, and the file extension ``.ipynb``. For |
|
54 | 54 | this reason, there is no confusion about using the same word "notebook" for |
|
55 | both the notebook space and the corresonding notebook document, since they are | |
|
55 | both the notebook space and the corresponding notebook document, since they are | |
|
56 | 56 | really one and the same concept (we could say that they are "isomorphic"). |
|
57 | 57 | |
|
58 | 58 | |
|
59 | 59 | Main features of the IPython Notebook web app |
|
60 | 60 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
61 | 61 | |
|
62 | 62 | The main features of the IPython Notebook app include: |
|
63 | 63 | |
|
64 | 64 | * In-browser editing for code, with automatic syntax highlighting and |
|
65 | 65 | indentation and tab completion/introspection. |
|
66 | 66 | |
|
67 | 67 | * Literate combination of code with rich text using the Markdown_ markup |
|
68 | 68 | language. |
|
69 | 69 | |
|
70 | 70 | * Mathematics is easily included within the Markdown using LaTeX notation, and |
|
71 | 71 | rendered natively by MathJax_. |
|
72 | 72 | |
|
73 | 73 | * Displays rich data representations (e.g. HTML / LaTeX / SVG) as the result |
|
74 | 74 | of computations. |
|
75 | 75 | |
|
76 | 76 | * Publication-quality figures in a range of formats (SVG / PNG), rendered by |
|
77 | 77 | the matplotlib_ library, may be included inline and exported. |
|
78 | 78 | |
|
79 | 79 | |
|
80 | 80 | .. _MathJax: http://www.mathjax.org/ |
|
81 | 81 | .. _matplotlib: http://matplotlib.org/ |
|
82 | 82 | .. _Markdown: http://daringfireball.net/projects/markdown/syntax |
|
83 | 83 | |
|
84 | 84 | |
|
85 | 85 | Notebook documents |
|
86 | 86 | ~~~~~~~~~~~~~~~~~~ |
|
87 | 87 | |
|
88 |
Notebook document files are |
|
|
89 | extension ``.ipynb``, stored in the working directory on your computer. | |
|
90 | Since the contents of the files are just plain text, they can be easily | |
|
91 | version-controlled and shared with colleagues. | |
|
92 | ||
|
93 | Internally, notebook document files use the JSON_ format, allowing them to | |
|
94 | store a *complete*, *reproducible*, *one-to-one* copy of the state of the | |
|
88 | Notebook document files are simple JSON_ files with the | |
|
89 | extension ``.ipynb``. | |
|
90 | Since JSON is just plain text, they can be easily version-controlled and shared with colleagues. | |
|
91 | The notebook stores a *complete*, *reproducible*, *one-to-one* copy of the state of the | |
|
95 | 92 | computational state as it is inside the Notebook app. All computations |
|
96 | 93 | carried out, and the corresponding results obtained, can be combined in |
|
97 | 94 | a literate way, interleaving executable code with rich text, mathematics, |
|
98 |
and |
|
|
95 | and rich representations of objects. | |
|
99 | 96 | |
|
100 | 97 | .. _JSON: http://en.wikipedia.org/wiki/JSON |
|
101 | 98 | |
|
102 | 99 | Notebooks may easily be exported to a range of static formats, including |
|
103 |
HTML (for example, for blog posts), PDF and slide shows, |
|
|
104 | newly-included `nbconvert script`_ functionality. | |
|
100 | HTML (for example, for blog posts), PDF and slide shows, | |
|
101 | via the new nbconvert_ command. | |
|
105 | 102 | |
|
106 |
Furthermore, any ``.ipynb`` notebook document |
|
|
107 |
URL can be shared via the `IPython Notebook Viewer |
|
|
108 |
loads the notebook document from the URL |
|
|
109 |
|
|
|
103 | Furthermore, any ``.ipynb`` notebook document available from a public | |
|
104 | URL can be shared via the `IPython Notebook Viewer <nbviewer>`_ service. | |
|
105 | This service loads the notebook document from the URL and will | |
|
106 | render it as a static web page. The results may thus be shared with a | |
|
110 | 107 | colleague, or as a public blog post, without other users needing to install |
|
111 | IPython themselves. | |
|
108 | IPython themselves. NbViewer is simply NbConvert as a simple heroku webservice. | |
|
112 | 109 | |
|
113 | 110 | See the :ref:`installation documentation <install_index>` for directions on |
|
114 | 111 | how to install the notebook and its dependencies. |
|
115 | 112 | |
|
116 |
.. _ |
|
|
113 | .. _nbviewer: http://nbviewer.ipython.org | |
|
117 | 114 | |
|
118 | 115 | .. note:: |
|
119 | 116 | |
|
120 | 117 | You can start more than one notebook server at the same time, if you want |
|
121 | 118 | to work on notebooks in different directories. By default the first |
|
122 | 119 | notebook server starts on port 8888, and later notebook servers search for |
|
123 | 120 | ports near that one. You can also manually specify the port with the |
|
124 | 121 | ``--port`` option. |
|
125 | 122 | |
|
126 | 123 | |
|
127 | 124 | Basic workflow in the IPython Notebook web app |
|
128 | 125 | ---------------------------------------------- |
|
129 | 126 | |
|
130 | 127 | Starting up |
|
131 | 128 | ~~~~~~~~~~~~ |
|
132 | 129 | |
|
133 | 130 | You can start running the Notebook web app using the following command:: |
|
134 | 131 | |
|
135 | 132 | $ ipython notebook |
|
136 | 133 | |
|
137 | 134 | (Here, and in the sequel, the initial ``$`` represents the shell prompt, |
|
138 | 135 | indicating that the command is to be run from the command line in a shell.) |
|
139 | 136 | |
|
140 | 137 |
The landing page of the IPython Notebook |
|
141 |
the notebooks currently available in the * |
|
|
138 | the notebooks currently available in the *notebook directory* (By default, the directory | |
|
142 | 139 | from which the notebook was started). |
|
143 | 140 | You can create new notebooks from the dashboard with the ``New Notebook`` |
|
144 | 141 | button, or open existing ones by clicking on their name. |
|
145 | 142 | You can also drag and drop ``.ipynb`` notebooks and standard ``.py`` Python |
|
146 | 143 | source code files into the notebook list area. |
|
147 | 144 | |
|
148 | 145 | |
|
149 | 146 | You can open an existing notebook directly, without having to go via the |
|
150 | 147 | dashboard, with: |
|
151 | 148 | |
|
152 | 149 | ipython notebook my_notebook |
|
153 | 150 | |
|
154 | 151 | The `.ipynb` extension is assumed if no extension is given. |
|
155 | 152 | |
|
156 | 153 | The `File | Open...` menu option will open the dashboard in a new browser tab, |
|
157 | 154 | to allow you to select a current notebook |
|
158 |
from the |
|
|
155 | from the notebook directory or to create a new notebook. | |
|
159 | 156 | |
|
160 | 157 | |
|
161 | 158 | |
|
162 | 159 | Notebook user interface |
|
163 | 160 | ~~~~~~~~~~~~~~~~~~~~~~~ |
|
164 | 161 | |
|
165 | 162 | When you open a new notebook document in the Notebook, you will be presented |
|
166 | 163 | with the title associated to the notebook space/document, a *menu bar*, a |
|
167 | 164 | *toolbar* and an empty *input cell*. |
|
168 | 165 | |
|
169 | 166 | Notebook title |
|
170 | 167 | ^^^^^^^^^^^^^^ |
|
171 | 168 | The title of the notebook document that is currently being edited is displayed |
|
172 | 169 | at the top of the page, next to the ``IP[y]: Notebook`` logo. This title may |
|
173 | 170 | be edited directly by clicking on it. The title is reflected in the name of |
|
174 | 171 | the ``.ipynb`` notebook document file that is saved. |
|
175 | 172 | |
|
176 | 173 | Menu bar |
|
177 | 174 | ^^^^^^^^ |
|
178 | 175 | The menu bar presents different options that may be used to manipulate the way |
|
179 | 176 | the Notebook functions. |
|
180 | 177 | |
|
181 | 178 | Toolbar |
|
182 | 179 | ^^^^^^^ |
|
183 | 180 | The tool bar gives a quick way of accessing the most-used operations within |
|
184 | 181 | the Notebook, by clicking on an icon. |
|
185 | 182 | |
|
186 | 183 | |
|
187 | 184 | Creating a new notebook document |
|
188 | 185 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
189 | 186 | |
|
190 | 187 | A new notebook space/document may be created at any time, either from the |
|
191 | 188 | dashboard, or using the `File | New` menu option from within an active |
|
192 |
notebook. The new notebook is created within the same |
|
|
189 | notebook. The new notebook is created within the same directory and | |
|
193 | 190 | will open in a new browser tab. It will also be reflected as a new entry in |
|
194 | 191 | the notebook list on the dashboard. |
|
195 | 192 | |
|
196 | 193 | |
|
197 | 194 | Structure of a notebook document |
|
198 | 195 | -------------------------------- |
|
199 | 196 | |
|
200 | 197 | Input cells |
|
201 | 198 | ~~~~~~~~~~~ |
|
202 | 199 | Input cells are at the core of the functionality of the IPython Notebook. |
|
203 | 200 | They are regions in the document in which you can enter different types of |
|
204 | 201 | text and commands. To *execute* or *run* the *current cell*, i.e. the cell |
|
205 | 202 | under the cursor, you can use the :kbd:`Shift-Enter` key combination. |
|
206 | 203 | This tells the Notebook app to perform the relevant operation for each type of |
|
207 | 204 | cell (see below), and then to display the resulting output. |
|
208 | 205 | |
|
209 | 206 | The notebook consists of a sequence of input cells, labelled ``In[n]``, which |
|
210 | 207 | may be executed in a non-linear way, and outputs ``Out[n]``, where ``n`` is a |
|
211 | 208 | number which denotes the order in which the cells were executed over the |
|
212 | 209 | history of the computational process. The contents of all of these cells are |
|
213 | 210 | accessible as Python variables with the same names, forming a complete record |
|
214 | 211 | of the history of the computation. |
|
215 | 212 | |
|
216 | 213 | |
|
217 | 214 | |
|
218 | 215 | Input cell types |
|
219 | 216 | ~~~~~~~~~~~~~~~~ |
|
220 | 217 | Each IPython input cell has a *cell type*, of which there is a restricted |
|
221 | 218 | number. The type of a cell may be set by using the cell type dropdown on the |
|
222 | 219 | toolbar, or via the following keyboard shortcuts: |
|
223 | 220 | |
|
224 | 221 | * **code**: :kbd:`Ctrl-m y` |
|
225 | 222 | * **markdown**: :kbd:`Ctrl-m m` |
|
226 | 223 | * **raw**: :kbd:`Ctrl-m t` |
|
227 | 224 | * **heading**: :kbd:`Ctrl-m 1` - :kbd:`Ctrl-m 6` |
|
228 | 225 | |
|
229 | 226 | Upon initial creation, each input cell is by default a code cell. |
|
230 | 227 | |
|
231 | 228 | |
|
232 | 229 | Code cells |
|
233 | 230 | ^^^^^^^^^^ |
|
234 | 231 | A *code input cell* allows you to edit code inline within the cell, with full |
|
235 | 232 | syntax highlighting and autocompletion/introspection. By default, the language |
|
236 | 233 | associated to a code cell is Python, but other languages, such as ``julia`` |
|
237 | 234 | and ``R``, can be handled using magic commands (see below). |
|
238 | 235 | |
|
239 | 236 | When a code cell is executed with :kbd:`Shift-Enter`, the code that it |
|
240 | 237 | contains is transparently exported and run in that language (with automatic |
|
241 | 238 | compiling, etc., if necessary). The result that is returned from this |
|
242 | 239 | computation is then displayed in the notebook space as the cell's |
|
243 | 240 | *output*. If this output is of a textual nature, it is placed into a |
|
244 | 241 | numbered *output cell*. However, many other possible forms of output are also |
|
245 | 242 | possible, including ``matplotlib`` figures and HTML tables (as used, for |
|
246 | 243 | example, in the ``pandas`` data analyis package). This is known as IPython's |
|
247 | 244 | *rich display* capability. |
|
248 | 245 | |
|
249 | 246 | |
|
250 | 247 | Markdown cells |
|
251 | 248 | ^^^^^^^^^^^^^^ |
|
252 | 249 | You can document the computational process in a literate way, alternating |
|
253 | 250 | descriptive text with code, using *rich text*. In IPython this is accomplished |
|
254 | 251 | by marking up text with the Markdown language. The corresponding cells are |
|
255 | 252 | called *Markdown input cells*. The Markdown language provides a simple way to |
|
256 | 253 | perform this text markup, that is, to specify which parts of the text should |
|
257 | 254 | be emphasized (italics), bold, form lists, etc. |
|
258 | 255 | |
|
259 | 256 | |
|
260 | 257 | When a Markdown input cell is executed, the Markdown code is converted into |
|
261 | 258 | the corresponding formatted rich text. This output then *replaces* the |
|
262 | 259 | original Markdown input cell, leaving just the visually-significant marked up |
|
263 | 260 | rich text. Markdown allows arbitrary HTML code for formatting. |
|
264 | 261 | |
|
265 | 262 | Within Markdown cells, you can also include *mathematics* in a straightforward |
|
266 | 263 | way, using standard LaTeX notation: ``$...$`` for inline mathematics and |
|
267 | 264 | ``$$...$$`` for displayed mathematics. When the Markdown cell is executed, |
|
268 | 265 | the LaTeX portions are automatically rendered in the HTML output as equations |
|
269 | 266 | with high quality typography. This is made possible by MathJax_, which |
|
270 | supports a `large subset`_ of LaTeX functionality | |
|
267 | supports a `large subset <mathjax_tex>`_ of LaTeX functionality | |
|
271 | 268 | |
|
272 |
.. _ |
|
|
269 | .. _mathjax_tex: http://docs.mathjax.org/en/latest/tex.html | |
|
273 | 270 | |
|
274 | 271 | Standard mathematics environments defined by LaTeX and AMS-LaTeX (the |
|
275 | 272 | `amsmath` package) also work, such as |
|
276 | 273 | ``\begin{equation}...\end{equation}``, and ``\begin{align}...\end{align}``. |
|
277 | 274 | New LaTeX macros may be defined using standard methods, |
|
278 | 275 | such as ``\newcommand``, by placing them anywhere *between math delimiters* in |
|
279 | 276 | a Markdown cell. These definitions are then available throughout the rest of |
|
280 | 277 | the IPython session. (Note, however, that more care must be taken when using |
|
281 |
|
|
|
278 | nbconvert_ to output to LaTeX). | |
|
282 | 279 | |
|
283 | 280 | Raw input cells |
|
284 | 281 | ~~~~~~~~~~~~~~~ |
|
285 | *Raw* input cells provide a place in which you can put additional information | |
|
286 | which you do not want to evaluated by the Notebook. This can be used, for | |
|
287 | example, to include extra information that is needed when exporting to a | |
|
288 | certain format. The output after evaluating a raw cell is just a verbatim copy | |
|
289 | of the input. | |
|
282 | ||
|
283 | *Raw* input cells provide a place in which you can write *output* directly. | |
|
284 | Raw cells are not evaluated by the Notebook, and have no output. | |
|
285 | When passed through nbconvert, Raw cells arrive in the destination format unmodified, | |
|
286 | allowing you to type full latex into a raw cell, which will only be rendered | |
|
287 | by latex after conversion by nbconvert. | |
|
290 | 288 | |
|
291 | 289 | Heading cells |
|
292 | 290 | ~~~~~~~~~~~~~ |
|
291 | ||
|
293 | 292 | You can provide a conceptual structure for your computational document as a |
|
294 | 293 | whole using different levels of headings; there are 6 levels available, from |
|
295 | 294 | level 1 (top level) down to level 6 (paragraph). These can be used later for |
|
296 | 295 | constructing tables of contents, etc. |
|
297 | 296 | |
|
298 | 297 | As with Markdown cells, a heading input cell is replaced by a rich text |
|
299 | 298 | rendering of the heading when the cell is executed. |
|
300 | 299 | |
|
301 | 300 | |
|
302 | 301 | Basic workflow |
|
303 | 302 | -------------- |
|
303 | ||
|
304 | 304 | The normal workflow in a notebook is, then, quite similar to a standard |
|
305 | 305 | IPython session, with the difference that you can edit cells in-place multiple |
|
306 | 306 | times until you obtain the desired results, rather than having to |
|
307 | 307 | rerun separate scripts with the ``%run`` magic command. (Magic commands do, |
|
308 | 308 | however, also work in the notebook; see below). |
|
309 | 309 | |
|
310 | 310 | Typically, you will work on a computational problem in pieces, organizing |
|
311 | 311 | related ideas into cells and moving forward once previous parts work |
|
312 | 312 | correctly. This is much more convenient for interactive exploration than |
|
313 | 313 | breaking up a computation into scripts that must be executed together, as was |
|
314 | 314 | previously necessary, especially if parts of them take a long time to run |
|
315 | 315 | |
|
316 | 316 | The only significant limitation that the Notebook currently has, compared to |
|
317 | 317 | the Qt console, is that it cannot run any code that expects input from the |
|
318 | 318 | kernel (such as scripts that call :func:`raw_input`). Very importantly, this |
|
319 | 319 | means that the ``%debug`` magic does *not* currently work in the notebook! |
|
320 | 320 | |
|
321 | 321 | This limitation will be overcome in the future, but in the meantime, there is |
|
322 | 322 | a simple solution for debugging: you can attach a Qt console to your existing |
|
323 | 323 | notebook kernel, and run ``%debug`` from the Qt console. |
|
324 | 324 | If your notebook is running on a local computer (i.e. if you are accessing it |
|
325 | 325 | via your localhost address at ``127.0.0.1``), then you can just type |
|
326 | 326 | ``%qtconsole`` in the notebook and a Qt console will open up, connected to |
|
327 | 327 | that same kernel. |
|
328 | 328 | |
|
329 | 329 | At certain moments, it may be necessary to interrupt a calculation which is |
|
330 | 330 | taking too long to complete. This may be done with the ``Kernel | Interrupt`` |
|
331 | 331 | menu option, or the :kbd:``Ctrl-i`` keyboard shortcut. |
|
332 | 332 | Similarly, it may be necessary or desirable to restart the whole computational |
|
333 | 333 | process, with the ``Kernel | Restart`` menu option or :kbd:``Ctrl-.`` |
|
334 | 334 | shortcut. This gives an equivalent state to loading the notebook document |
|
335 | 335 | afresh. |
|
336 | 336 | |
|
337 | 337 | |
|
338 | 338 | .. warning:: |
|
339 | 339 | |
|
340 | 340 | While in simple cases you can "roundtrip" a notebook to Python, edit the |
|
341 | 341 | Python file, and then import it back without loss of main content, this is |
|
342 | 342 | in general *not guaranteed to work*. First, there is extra metadata |
|
343 | 343 | saved in the notebook that may not be saved to the ``.py`` format. And as |
|
344 | 344 | the notebook format evolves in complexity, there will be attributes of the |
|
345 | 345 | notebook that will not survive a roundtrip through the Python form. You |
|
346 | 346 | should think of the Python format as a way to output a script version of a |
|
347 | 347 | notebook and the import capabilities as a way to load existing code to get |
|
348 | 348 | a notebook started. But the Python version is *not* an alternate notebook |
|
349 | 349 | format. |
|
350 | 350 | |
|
351 | 351 | |
|
352 | 352 | Keyboard shortcuts |
|
353 | 353 | ~~~~~~~~~~~~~~~~~~ |
|
354 | 354 | All actions in the notebook can be achieved with the mouse, but keyboard |
|
355 | 355 | shortcuts are also available for the most common ones, so that productive use |
|
356 | 356 | of the notebook can be achieved with minimal mouse usage. The main shortcuts |
|
357 | 357 | to remember are the following: |
|
358 | 358 | |
|
359 | 359 | * :kbd:`Shift-Enter`: |
|
360 | 360 | |
|
361 | 361 | Execute the current cell, show output (if any), and jump to the next cell |
|
362 | 362 | below. If :kbd:`Shift-Enter` is invoked on the last input cell, a new code |
|
363 | 363 | cell will also be created. Note that in the notebook, typing :kbd:`Enter` |
|
364 | 364 | on its own *never* forces execution, but rather just inserts a new line in |
|
365 | 365 | the current input cell. In the Notebook it is thus always necessary to use |
|
366 | 366 | :kbd:`Shift-Enter` to execute the cell (or use the ``Cell | Run`` menu |
|
367 | 367 | item). |
|
368 | 368 | |
|
369 | 369 | * :kbd:`Ctrl-Enter`: |
|
370 | 370 | Execute the current cell as if it were in "terminal mode", where any |
|
371 | 371 | output is shown, but the cursor *remains* in the current cell. This is |
|
372 | 372 | convenient for doing quick experiments in place, or for querying things |
|
373 | 373 | like filesystem content, without needing to create additional cells that |
|
374 | 374 | you may not want to be saved in the notebook. |
|
375 | 375 | |
|
376 | 376 | * :kbd:`Alt-Enter`: |
|
377 | 377 | Executes the current cell, shows the output, and inserts a *new* input |
|
378 | 378 | cell between the current cell and the adjacent cell (if one exists). This |
|
379 | 379 | is thus a shortcut for the sequence :kbd:`Shift-Enter`, :kbd:`Ctrl-m a`. |
|
380 | 380 | (:kbd:`Ctrl-m a` adds a new cell above the current one.) |
|
381 | 381 | |
|
382 | 382 | * :kbd:`Ctrl-m`: |
|
383 | 383 | This is the prefix for *all* other shortcuts, which consist of :kbd:`Ctrl-m` |
|
384 | 384 | followed by a single letter or character. For example, if you type |
|
385 | 385 | :kbd:`Ctrl-m h` (that is, the sole letter :kbd:`h` after :kbd:`Ctrl-m`), |
|
386 | 386 | IPython will show you all the available keyboard shortcuts. |
|
387 | 387 | |
|
388 | 388 | |
|
389 | 389 | Magic commands |
|
390 | 390 | -------------- |
|
391 | 391 | Magic commands, or *magics*, are commands for controlling IPython itself. |
|
392 | 392 | They all begin with ``%`` and are entered into code input cells; the code |
|
393 | 393 | cells are executed as usual with :kbd:`Shift-Enter`. |
|
394 | 394 | |
|
395 | 395 | The magic commands call special functions defined by IPython which manipulate |
|
396 | 396 | the computational state in certain ways. |
|
397 | 397 | |
|
398 | 398 | There are two types of magics: |
|
399 | 399 | |
|
400 | 400 | - **line magics**: |
|
401 | 401 | |
|
402 | 402 | These begin with a single ``%`` and take as arguments the rest of the |
|
403 | 403 | *same line* of the code cell. Any other lines of the code cell are |
|
404 | 404 | treated as if they were part of a standard code cell. |
|
405 | 405 | |
|
406 | 406 | - **cell magics**: |
|
407 | 407 | |
|
408 | 408 | These begin with ``%%`` and operate on the *entire* remaining contents |
|
409 | 409 | of the code cell. |
|
410 | 410 | |
|
411 | 411 | Line magics |
|
412 | 412 | ~~~~~~~~~~~ |
|
413 | 413 | Some of the available line magics are the following: |
|
414 | 414 | |
|
415 | 415 | * ``%load filename``: |
|
416 | 416 | |
|
417 | 417 | Loads the contents of the file ``filename`` into a new code cell. This |
|
418 | 418 | can be a URL for a remote file. |
|
419 | 419 | |
|
420 | 420 | * ``%timeit code``: |
|
421 | 421 | |
|
422 | 422 | An easy way to time how long the single line of code ``code`` takes to |
|
423 | 423 | run |
|
424 | 424 | |
|
425 | 425 | * ``%config``: |
|
426 | 426 | |
|
427 | 427 | Configuration of the IPython Notebook |
|
428 | 428 | |
|
429 | 429 | * ``%lsmagic``: |
|
430 | 430 | |
|
431 | 431 | Provides a list of all available magic commands |
|
432 | 432 | |
|
433 | 433 | Cell magics |
|
434 | 434 | ~~~~~~~~~~~ |
|
435 | 435 | |
|
436 | 436 | * ``%%latex``: |
|
437 | 437 | |
|
438 | 438 | Renders the entire contents of the cell in LaTeX, without needing to use |
|
439 | 439 | explicit LaTeX delimiters. |
|
440 | 440 | |
|
441 | 441 | * ``%%bash``: |
|
442 | 442 | |
|
443 | 443 | The code cell is executed by sending it to be executed by ``bash``. The |
|
444 | 444 | output of the ``bash`` commands is captured and displayed in the |
|
445 | 445 | notebook. |
|
446 | 446 | |
|
447 | 447 | * ``%%file filename``: |
|
448 | 448 | |
|
449 | 449 | Writes the contents of the cell to the file ``filename``. |
|
450 | 450 | **Caution**: The file is over-written without warning! |
|
451 | 451 | |
|
452 | 452 | * ``%%R``: |
|
453 | 453 | |
|
454 | 454 | Execute the contents of the cell using the R language. |
|
455 | 455 | |
|
456 | 456 | * ``%%timeit``: |
|
457 | 457 | |
|
458 | 458 | Version of ``%timeit`` which times the entire block of code in the |
|
459 | 459 | current code cell. |
|
460 | 460 | |
|
461 | 461 | |
|
462 | 462 | |
|
463 | 463 | Several of the cell magics provide functionality to manipulate the filesystem |
|
464 | 464 | of a remote server to which you otherwise do not have access. |
|
465 | 465 | |
|
466 | 466 | |
|
467 | 467 | Plotting |
|
468 | 468 | -------- |
|
469 | 469 | One major feature of the Notebook is the ability to interact with |
|
470 | 470 | plots that are the output of running code cells. IPython is designed to work |
|
471 | 471 | seamlessly with the ``matplotlib`` plotting library to provide this |
|
472 | 472 | functionality. |
|
473 | 473 | |
|
474 | 474 | To set this up, before any plotting is performed you must execute the |
|
475 | 475 | ``%matplotlib`` magic command. This performs the necessary behind-the-scenes |
|
476 | 476 | setup for IPython to work correctly hand in hand with ``matplotlib``; it does |
|
477 | 477 | *not*, however, actually execute any Python ``import`` commands, that is, no |
|
478 | 478 | names are added to the namespace. |
|
479 | 479 | |
|
480 | 480 | For more agile *interactive* use of the notebook space, an alternative magic, |
|
481 | 481 | ``%pylab``, is provided. This does the same work as the ``%matplotlib`` magic, |
|
482 | 482 | but *in addition* it automatically executes a standard sequence of ``import`` |
|
483 | 483 | statements required to work with the ``%matplotlib`` library, importing the |
|
484 | 484 | following names into the namespace: |
|
485 | 485 | |
|
486 | 486 | ``numpy`` as ``np``; ``matplotlib.pyplot`` as ``plt``; |
|
487 | 487 | ``matplotlib``, ``pylab`` and ``mlab`` from ``matplotlib``; and *all names* |
|
488 | 488 | from within ``numpy`` and ``pylab``. |
|
489 | 489 | |
|
490 | 490 | However, the use of ``%pylab`` is discouraged, since names coming from |
|
491 | 491 | different packages may collide. In general, the use of ``from package import |
|
492 | 492 | *`` is discouraged. A better option is then:: |
|
493 | 493 | |
|
494 | 494 | %pylab --no-import-all |
|
495 | 495 | |
|
496 | 496 | which imports the names listed above, but does *not* perform this |
|
497 | 497 | ``import *`` imports. |
|
498 | 498 | |
|
499 | 499 | If the ``%matplotlib`` or ``%pylab` magics are called without an argument, the |
|
500 | 500 | output of a plotting command is displayed using the default ``matplotlib`` |
|
501 | 501 | backend in a separate window. Alternatively, the backend can be explicitly |
|
502 | 502 | requested using, for example:: |
|
503 | 503 | |
|
504 | 504 | %matplotlib gtk |
|
505 | 505 | |
|
506 | 506 | A particularly interesting backend is the ``inline`` backend. |
|
507 | 507 | This is applicable only for the IPython Notebook and the IPython Qtconsole. |
|
508 | 508 | It can be invoked as follows:: |
|
509 | 509 | |
|
510 | 510 | %matplotlib inline |
|
511 | 511 | |
|
512 | 512 | With this backend, output of plotting commands is displayed *inline* within |
|
513 | 513 | the notebook format, directly below the input cell that produced it. The |
|
514 | 514 | resulting plots will then also be stored in the notebook document. This |
|
515 | 515 | provides a key part of the functionality for reproducibility_ that the IPython |
|
516 | 516 | Notebook provides. |
|
517 | 517 | |
|
518 | 518 | .. _reproducibility: https://en.wikipedia.org/wiki/Reproducibility |
|
519 | 519 | |
|
520 | 520 | |
|
521 | 521 | |
|
522 | 522 | Configuring the IPython Notebook |
|
523 | 523 | -------------------------------- |
|
524 | 524 | The IPython Notebook can be run with a variety of command line arguments. |
|
525 | 525 | To see a list of available options enter:: |
|
526 | 526 | |
|
527 | 527 | $ ipython notebook --help |
|
528 | 528 | |
|
529 | 529 | Defaults for these options can also be set by creating a file named |
|
530 | 530 | ``ipython_notebook_config.py`` in your IPython *profile folder*. The profile |
|
531 | 531 | folder is a subfolder of your IPython directory; to find out where it is |
|
532 | 532 | located, run:: |
|
533 | 533 | |
|
534 | 534 | $ ipython locate |
|
535 | 535 | |
|
536 | 536 | To create a new set of default configuration files, with lots of information |
|
537 | 537 | on available options, use:: |
|
538 | 538 | |
|
539 | 539 | $ ipython profile create |
|
540 | 540 | |
|
541 | 541 | .. seealso: |
|
542 | 542 | |
|
543 | 543 | :ref:`config_overview`, in particular :ref:`Profiles`. |
|
544 | 544 | |
|
545 | 545 | |
|
546 | 546 | Importing `.py` files |
|
547 | 547 | ---------------------- |
|
548 | 548 | |
|
549 | 549 | |
|
550 | 550 | ``.py`` files will be imported into the IPython Notebook as a notebook with |
|
551 |
the same basename, but an ``.ipynb`` extension, located in the |
|
|
551 | the same basename, but an ``.ipynb`` extension, located in the notebook | |
|
552 | 552 | directory. The notebook created will have just one cell, which will contain |
|
553 | 553 | all the code in the ``.py`` file. You can later manually partition this into |
|
554 | 554 | individual cells using the ``Edit | Split Cell`` menu option, or the |
|
555 | 555 | :kbd:`Ctrl-m -` keyboard shortcut. |
|
556 | 556 | |
|
557 | 557 | .. Alternatively, prior to importing the ``.py``, you can manually add ``# < |
|
558 | 558 | nbformat>2</nbformat>`` at the start of the file, and then add separators for |
|
559 | 559 | text and code cells, to get a cleaner import with the file already broken into |
|
560 | 560 | individual cells. |
|
561 | 561 | |
|
562 | ||
|
563 | ||
|
564 | .. _Markdown: http://daringfireball.net/projects/markdown/basics |
General Comments 0
You need to be logged in to leave comments.
Login now