0
|
1 # -*- Mode: Shell-Script -*- Not really, but shows comments correctly |
|
2 # $Id: ipythonrc 2156 2007-03-19 02:32:19Z fperez $ |
|
3 |
|
4 #*************************************************************************** |
|
5 # |
|
6 # Configuration file for IPython -- ipythonrc format |
|
7 # |
|
8 # =========================================================== |
|
9 # Deprecation note: you should look into modifying ipy_user_conf.py (located |
|
10 # in ~/.ipython or ~/_ipython, depending on your platform) instead, it's a |
|
11 # more flexible and robust (and better supported!) configuration |
|
12 # method. |
|
13 # =========================================================== |
|
14 # |
|
15 # The format of this file is simply one of 'key value' lines. |
|
16 # Lines containing only whitespace at the beginning and then a # are ignored |
|
17 # as comments. But comments can NOT be put on lines with data. |
|
18 |
|
19 # The meaning and use of each key are explained below. |
|
20 |
|
21 #--------------------------------------------------------------------------- |
|
22 # Section: included files |
|
23 |
|
24 # Put one or more *config* files (with the syntax of this file) you want to |
|
25 # include. For keys with a unique value the outermost file has precedence. For |
|
26 # keys with multiple values, they all get assembled into a list which then |
|
27 # gets loaded by IPython. |
|
28 |
|
29 # In this file, all lists of things should simply be space-separated. |
|
30 |
|
31 # This allows you to build hierarchies of files which recursively load |
|
32 # lower-level services. If this is your main ~/.ipython/ipythonrc file, you |
|
33 # should only keep here basic things you always want available. Then you can |
|
34 # include it in every other special-purpose config file you create. |
|
35 include |
|
36 |
|
37 #--------------------------------------------------------------------------- |
|
38 # Section: startup setup |
|
39 |
|
40 # These are mostly things which parallel a command line option of the same |
|
41 # name. |
|
42 |
|
43 # Keys in this section should only appear once. If any key from this section |
|
44 # is encountered more than once, the last value remains, all earlier ones get |
|
45 # discarded. |
|
46 |
|
47 |
|
48 # Automatic calling of callable objects. If set to 1 or 2, callable objects |
|
49 # are automatically called when invoked at the command line, even if you don't |
|
50 # type parentheses. IPython adds the parentheses for you. For example: |
|
51 |
|
52 #In [1]: str 45 |
|
53 #------> str(45) |
|
54 #Out[1]: '45' |
|
55 |
|
56 # IPython reprints your line with '---->' indicating that it added |
|
57 # parentheses. While this option is very convenient for interactive use, it |
|
58 # may occasionally cause problems with objects which have side-effects if |
|
59 # called unexpectedly. |
|
60 |
|
61 # The valid values for autocall are: |
|
62 |
|
63 # autocall 0 -> disabled (you can toggle it at runtime with the %autocall magic) |
|
64 |
|
65 # autocall 1 -> active, but do not apply if there are no arguments on the line. |
|
66 |
|
67 # In this mode, you get: |
|
68 |
|
69 #In [1]: callable |
|
70 #Out[1]: <built-in function callable> |
|
71 |
|
72 #In [2]: callable 'hello' |
|
73 #------> callable('hello') |
|
74 #Out[2]: False |
|
75 |
|
76 # 2 -> Active always. Even if no arguments are present, the callable object |
|
77 # is called: |
|
78 |
|
79 #In [4]: callable |
|
80 #------> callable() |
|
81 |
|
82 # Note that even with autocall off, you can still use '/' at the start of a |
|
83 # line to treat the first argument on the command line as a function and add |
|
84 # parentheses to it: |
|
85 |
|
86 #In [8]: /str 43 |
|
87 #------> str(43) |
|
88 #Out[8]: '43' |
|
89 |
|
90 autocall 1 |
|
91 |
|
92 # Auto-edit syntax errors. When you use the %edit magic in ipython to edit |
|
93 # source code (see the 'editor' variable below), it is possible that you save |
|
94 # a file with syntax errors in it. If this variable is true, IPython will ask |
|
95 # you whether to re-open the editor immediately to correct such an error. |
|
96 |
|
97 autoedit_syntax 0 |
|
98 |
|
99 # Auto-indent. IPython can recognize lines ending in ':' and indent the next |
|
100 # line, while also un-indenting automatically after 'raise' or 'return'. |
|
101 |
|
102 # This feature uses the readline library, so it will honor your ~/.inputrc |
|
103 # configuration (or whatever file your INPUTRC variable points to). Adding |
|
104 # the following lines to your .inputrc file can make indent/unindenting more |
|
105 # convenient (M-i indents, M-u unindents): |
|
106 |
|
107 # $if Python |
|
108 # "\M-i": " " |
|
109 # "\M-u": "\d\d\d\d" |
|
110 # $endif |
|
111 |
|
112 # The feature is potentially a bit dangerous, because it can cause problems |
|
113 # with pasting of indented code (the pasted code gets re-indented on each |
|
114 # line). But it's a huge time-saver when working interactively. The magic |
|
115 # function %autoindent allows you to toggle it on/off at runtime. |
|
116 |
|
117 autoindent 1 |
|
118 |
|
119 # Auto-magic. This gives you access to all the magic functions without having |
|
120 # to prepend them with an % sign. If you define a variable with the same name |
|
121 # as a magic function (say who=1), you will need to access the magic function |
|
122 # with % (%who in this example). However, if later you delete your variable |
|
123 # (del who), you'll recover the automagic calling form. |
|
124 |
|
125 # Considering that many magic functions provide a lot of shell-like |
|
126 # functionality, automagic gives you something close to a full Python+system |
|
127 # shell environment (and you can extend it further if you want). |
|
128 |
|
129 automagic 1 |
|
130 |
|
131 # Size of the output cache. After this many entries are stored, the cache will |
|
132 # get flushed. Depending on the size of your intermediate calculations, you |
|
133 # may have memory problems if you make it too big, since keeping things in the |
|
134 # cache prevents Python from reclaiming the memory for old results. Experiment |
|
135 # with a value that works well for you. |
|
136 |
|
137 # If you choose cache_size 0 IPython will revert to python's regular >>> |
|
138 # unnumbered prompt. You will still have _, __ and ___ for your last three |
|
139 # results, but that will be it. No dynamic _1, _2, etc. will be created. If |
|
140 # you are running on a slow machine or with very limited memory, this may |
|
141 # help. |
|
142 |
|
143 cache_size 1000 |
|
144 |
|
145 # Classic mode: Setting 'classic 1' you lose many of IPython niceties, |
|
146 # but that's your choice! Classic 1 -> same as IPython -classic. |
|
147 # Note that this is _not_ the normal python interpreter, it's simply |
|
148 # IPython emulating most of the classic interpreter's behavior. |
|
149 classic 0 |
|
150 |
|
151 # colors - Coloring option for prompts and traceback printouts. |
|
152 |
|
153 # Currently available schemes: NoColor, Linux, LightBG. |
|
154 |
|
155 # This option allows coloring the prompts and traceback printouts. This |
|
156 # requires a terminal which can properly handle color escape sequences. If you |
|
157 # are having problems with this, use the NoColor scheme (uses no color escapes |
|
158 # at all). |
|
159 |
|
160 # The Linux option works well in linux console type environments: dark |
|
161 # background with light fonts. |
|
162 |
|
163 # LightBG is similar to Linux but swaps dark/light colors to be more readable |
|
164 # in light background terminals. |
|
165 |
|
166 # keep uncommented only the one you want: |
|
167 colors Linux |
|
168 #colors LightBG |
|
169 #colors NoColor |
|
170 |
|
171 ######################## |
|
172 # Note to Windows users |
|
173 # |
|
174 # Color and readline support is avaialble to Windows users via Gary Bishop's |
|
175 # readline library. You can find Gary's tools at |
|
176 # http://sourceforge.net/projects/uncpythontools. |
|
177 # Note that his readline module requires in turn the ctypes library, available |
|
178 # at http://starship.python.net/crew/theller/ctypes. |
|
179 ######################## |
|
180 |
|
181 # color_info: IPython can display information about objects via a set of |
|
182 # functions, and optionally can use colors for this, syntax highlighting |
|
183 # source code and various other elements. This information is passed through a |
|
184 # pager (it defaults to 'less' if $PAGER is not set). |
|
185 |
|
186 # If your pager has problems, try to setting it to properly handle escapes |
|
187 # (see the less manpage for detail), or disable this option. The magic |
|
188 # function %color_info allows you to toggle this interactively for testing. |
|
189 |
|
190 color_info 1 |
|
191 |
|
192 # confirm_exit: set to 1 if you want IPython to confirm when you try to exit |
|
193 # with an EOF (Control-d in Unix, Control-Z/Enter in Windows). Note that using |
|
194 # the magic functions %Exit or %Quit you can force a direct exit, bypassing |
|
195 # any confirmation. |
|
196 |
|
197 confirm_exit 0 |
|
198 |
|
199 # Use deep_reload() as a substitute for reload() by default. deep_reload() is |
|
200 # still available as dreload() and appears as a builtin. |
|
201 |
|
202 deep_reload 0 |
|
203 |
|
204 # Which editor to use with the %edit command. If you leave this at 0, IPython |
|
205 # will honor your EDITOR environment variable. Since this editor is invoked on |
|
206 # the fly by ipython and is meant for editing small code snippets, you may |
|
207 # want to use a small, lightweight editor here. |
|
208 |
|
209 # For Emacs users, setting up your Emacs server properly as described in the |
|
210 # manual is a good idea. An alternative is to use jed, a very light editor |
|
211 # with much of the feel of Emacs (though not as powerful for heavy-duty work). |
|
212 |
|
213 editor 0 |
|
214 |
|
215 # log 1 -> same as ipython -log. This automatically logs to ./ipython.log |
|
216 log 0 |
|
217 |
|
218 # Same as ipython -Logfile YourLogfileName. |
|
219 # Don't use with log 1 (use one or the other) |
|
220 logfile '' |
|
221 |
|
222 # banner 0 -> same as ipython -nobanner |
|
223 banner 0 |
|
224 |
|
225 # messages 0 -> same as ipython -nomessages |
|
226 messages 1 |
|
227 |
|
228 # Automatically call the pdb debugger after every uncaught exception. If you |
|
229 # are used to debugging using pdb, this puts you automatically inside of it |
|
230 # after any call (either in IPython or in code called by it) which triggers an |
|
231 # exception which goes uncaught. |
|
232 pdb 0 |
|
233 |
|
234 # Enable the pprint module for printing. pprint tends to give a more readable |
|
235 # display (than print) for complex nested data structures. |
|
236 pprint 1 |
|
237 |
|
238 # Prompt strings |
|
239 |
|
240 # Most bash-like escapes can be used to customize IPython's prompts, as well as |
|
241 # a few additional ones which are IPython-specific. All valid prompt escapes |
|
242 # are described in detail in the Customization section of the IPython HTML/PDF |
|
243 # manual. |
|
244 |
|
245 # Use \# to represent the current prompt number, and quote them to protect |
|
246 # spaces. |
|
247 prompt_in1 'In [\#]: ' |
|
248 |
|
249 # \D is replaced by as many dots as there are digits in the |
|
250 # current value of \#. |
|
251 prompt_in2 ' .\D.: ' |
|
252 |
|
253 prompt_out 'Out[\#]: ' |
|
254 |
|
255 # Select whether to left-pad the output prompts to match the length of the |
|
256 # input ones. This allows you for example to use a simple '>' as an output |
|
257 # prompt, and yet have the output line up with the input. If set to false, |
|
258 # the output prompts will be unpadded (flush left). |
|
259 prompts_pad_left 1 |
|
260 |
|
261 # Pylab support: when ipython is started with the -pylab switch, by default it |
|
262 # executes 'from matplotlib.pylab import *'. Set this variable to false if you |
|
263 # want to disable this behavior. |
|
264 |
|
265 # For details on pylab, see the matplotlib website: |
|
266 # http://matplotlib.sf.net |
|
267 pylab_import_all 1 |
|
268 |
|
269 |
|
270 # quick 1 -> same as ipython -quick |
|
271 quick 0 |
|
272 |
|
273 # Use the readline library (1) or not (0). Most users will want this on, but |
|
274 # if you experience strange problems with line management (mainly when using |
|
275 # IPython inside Emacs buffers) you may try disabling it. Not having it on |
|
276 # prevents you from getting command history with the arrow keys, searching and |
|
277 # name completion using TAB. |
|
278 |
|
279 readline 1 |
|
280 |
|
281 # Screen Length: number of lines of your screen. This is used to control |
|
282 # printing of very long strings. Strings longer than this number of lines will |
|
283 # be paged with the less command instead of directly printed. |
|
284 |
|
285 # The default value for this is 0, which means IPython will auto-detect your |
|
286 # screen size every time it needs to print. If for some reason this isn't |
|
287 # working well (it needs curses support), specify it yourself. Otherwise don't |
|
288 # change the default. |
|
289 |
|
290 screen_length 0 |
|
291 |
|
292 # Prompt separators for input and output. |
|
293 # Use \n for newline explicitly, without quotes. |
|
294 # Use 0 (like at the cmd line) to turn off a given separator. |
|
295 |
|
296 # The structure of prompt printing is: |
|
297 # (SeparateIn)Input.... |
|
298 # (SeparateOut)Output... |
|
299 # (SeparateOut2), # that is, no newline is printed after Out2 |
|
300 # By choosing these you can organize your output any way you want. |
|
301 |
|
302 separate_in \n |
|
303 separate_out 0 |
|
304 separate_out2 0 |
|
305 |
|
306 # 'nosep 1' is a shorthand for '-SeparateIn 0 -SeparateOut 0 -SeparateOut2 0'. |
|
307 # Simply removes all input/output separators, overriding the choices above. |
|
308 nosep 0 |
|
309 |
|
310 # Wildcard searches - IPython has a system for searching names using |
|
311 # shell-like wildcards; type %psearch? for details. This variables sets |
|
312 # whether by default such searches should be case sensitive or not. You can |
|
313 # always override the default at the system command line or the IPython |
|
314 # prompt. |
|
315 |
|
316 wildcards_case_sensitive 1 |
|
317 |
|
318 # Object information: at what level of detail to display the string form of an |
|
319 # object. If set to 0, ipython will compute the string form of any object X, |
|
320 # by calling str(X), when X? is typed. If set to 1, str(X) will only be |
|
321 # computed when X?? is given, and if set to 2 or higher, it will never be |
|
322 # computed (there is no X??? level of detail). This is mostly of use to |
|
323 # people who frequently manipulate objects whose string representation is |
|
324 # extremely expensive to compute. |
|
325 |
|
326 object_info_string_level 0 |
|
327 |
|
328 # xmode - Exception reporting mode. |
|
329 |
|
330 # Valid modes: Plain, Context and Verbose. |
|
331 |
|
332 # Plain: similar to python's normal traceback printing. |
|
333 |
|
334 # Context: prints 5 lines of context source code around each line in the |
|
335 # traceback. |
|
336 |
|
337 # Verbose: similar to Context, but additionally prints the variables currently |
|
338 # visible where the exception happened (shortening their strings if too |
|
339 # long). This can potentially be very slow, if you happen to have a huge data |
|
340 # structure whose string representation is complex to compute. Your computer |
|
341 # may appear to freeze for a while with cpu usage at 100%. If this occurs, you |
|
342 # can cancel the traceback with Ctrl-C (maybe hitting it more than once). |
|
343 |
|
344 #xmode Plain |
|
345 xmode Context |
|
346 #xmode Verbose |
|
347 |
|
348 # multi_line_specials: if true, allow magics, aliases and shell escapes (via |
|
349 # !cmd) to be used in multi-line input (like for loops). For example, if you |
|
350 # have this active, the following is valid in IPython: |
|
351 # |
|
352 #In [17]: for i in range(3): |
|
353 # ....: mkdir $i |
|
354 # ....: !touch $i/hello |
|
355 # ....: ls -l $i |
|
356 |
|
357 multi_line_specials 1 |
|
358 |
|
359 |
|
360 # System calls: When IPython makes system calls (e.g. via special syntax like |
|
361 # !cmd or !!cmd, or magics like %sc or %sx), it can print the command it is |
|
362 # executing to standard output, prefixed by a header string. |
|
363 |
|
364 system_header "IPython system call: " |
|
365 |
|
366 system_verbose 1 |
|
367 |
|
368 # wxversion: request a specific wxPython version (used for -wthread) |
|
369 |
|
370 # Set this to the value of wxPython you want to use, but note that this |
|
371 # feature requires you to have the wxversion Python module to work. If you |
|
372 # don't have the wxversion module (try 'import wxversion' at the prompt to |
|
373 # check) or simply want to leave the system to pick up the default, leave this |
|
374 # variable at 0. |
|
375 |
|
376 wxversion 0 |
|
377 |
|
378 #--------------------------------------------------------------------------- |
|
379 # Section: Readline configuration (readline is not available for MS-Windows) |
|
380 |
|
381 # This is done via the following options: |
|
382 |
|
383 # (i) readline_parse_and_bind: this option can appear as many times as you |
|
384 # want, each time defining a string to be executed via a |
|
385 # readline.parse_and_bind() command. The syntax for valid commands of this |
|
386 # kind can be found by reading the documentation for the GNU readline library, |
|
387 # as these commands are of the kind which readline accepts in its |
|
388 # configuration file. |
|
389 |
|
390 # The TAB key can be used to complete names at the command line in one of two |
|
391 # ways: 'complete' and 'menu-complete'. The difference is that 'complete' only |
|
392 # completes as much as possible while 'menu-complete' cycles through all |
|
393 # possible completions. Leave the one you prefer uncommented. |
|
394 |
|
395 readline_parse_and_bind tab: complete |
|
396 #readline_parse_and_bind tab: menu-complete |
|
397 |
|
398 # This binds Control-l to printing the list of all possible completions when |
|
399 # there is more than one (what 'complete' does when hitting TAB twice, or at |
|
400 # the first TAB if show-all-if-ambiguous is on) |
|
401 readline_parse_and_bind "\C-l": possible-completions |
|
402 |
|
403 # This forces readline to automatically print the above list when tab |
|
404 # completion is set to 'complete'. You can still get this list manually by |
|
405 # using the key bound to 'possible-completions' (Control-l by default) or by |
|
406 # hitting TAB twice. Turning this on makes the printing happen at the first |
|
407 # TAB. |
|
408 readline_parse_and_bind set show-all-if-ambiguous on |
|
409 |
|
410 # If you have TAB set to complete names, you can rebind any key (Control-o by |
|
411 # default) to insert a true TAB character. |
|
412 readline_parse_and_bind "\C-o": tab-insert |
|
413 |
|
414 # These commands allow you to indent/unindent easily, with the 4-space |
|
415 # convention of the Python coding standards. Since IPython's internal |
|
416 # auto-indent system also uses 4 spaces, you should not change the number of |
|
417 # spaces in the code below. |
|
418 readline_parse_and_bind "\M-i": " " |
|
419 readline_parse_and_bind "\M-o": "\d\d\d\d" |
|
420 readline_parse_and_bind "\M-I": "\d\d\d\d" |
|
421 |
|
422 # Bindings for incremental searches in the history. These searches use the |
|
423 # string typed so far on the command line and search anything in the previous |
|
424 # input history containing them. |
|
425 readline_parse_and_bind "\C-r": reverse-search-history |
|
426 readline_parse_and_bind "\C-s": forward-search-history |
|
427 |
|
428 # Bindings for completing the current line in the history of previous |
|
429 # commands. This allows you to recall any previous command by typing its first |
|
430 # few letters and hitting Control-p, bypassing all intermediate commands which |
|
431 # may be in the history (much faster than hitting up-arrow 50 times!) |
|
432 readline_parse_and_bind "\C-p": history-search-backward |
|
433 readline_parse_and_bind "\C-n": history-search-forward |
|
434 |
|
435 # I also like to have the same functionality on the plain arrow keys. If you'd |
|
436 # rather have the arrows use all the history (and not just match what you've |
|
437 # typed so far), comment out or delete the next two lines. |
|
438 readline_parse_and_bind "\e[A": history-search-backward |
|
439 readline_parse_and_bind "\e[B": history-search-forward |
|
440 |
|
441 # These are typically on by default under *nix, but not win32. |
|
442 readline_parse_and_bind "\C-k": kill-line |
|
443 readline_parse_and_bind "\C-u": unix-line-discard |
|
444 |
|
445 # (ii) readline_remove_delims: a string of characters to be removed from the |
|
446 # default word-delimiters list used by readline, so that completions may be |
|
447 # performed on strings which contain them. |
|
448 |
|
449 readline_remove_delims -/~ |
|
450 |
|
451 # (iii) readline_merge_completions: whether to merge the result of all |
|
452 # possible completions or not. If true, IPython will complete filenames, |
|
453 # python names and aliases and return all possible completions. If you set it |
|
454 # to false, each completer is used at a time, and only if it doesn't return |
|
455 # any completions is the next one used. |
|
456 |
|
457 # The default order is: [python_matches, file_matches, alias_matches] |
|
458 |
|
459 readline_merge_completions 1 |
|
460 |
|
461 # (iv) readline_omit__names: normally hitting <tab> after a '.' in a name |
|
462 # will complete all attributes of an object, including all the special methods |
|
463 # whose names start with single or double underscores (like __getitem__ or |
|
464 # __class__). |
|
465 |
|
466 # This variable allows you to control this completion behavior: |
|
467 |
|
468 # readline_omit__names 1 -> completion will omit showing any names starting |
|
469 # with two __, but it will still show names starting with one _. |
|
470 |
|
471 # readline_omit__names 2 -> completion will omit all names beginning with one |
|
472 # _ (which obviously means filtering out the double __ ones). |
|
473 |
|
474 # Even when this option is set, you can still see those names by explicitly |
|
475 # typing a _ after the period and hitting <tab>: 'name._<tab>' will always |
|
476 # complete attribute names starting with '_'. |
|
477 |
|
478 # This option is off by default so that new users see all attributes of any |
|
479 # objects they are dealing with. |
|
480 |
|
481 readline_omit__names 0 |
|
482 |
|
483 #--------------------------------------------------------------------------- |
|
484 # Section: modules to be loaded with 'import ...' |
|
485 |
|
486 # List, separated by spaces, the names of the modules you want to import |
|
487 |
|
488 # Example: |
|
489 # import_mod sys os |
|
490 # will produce internally the statements |
|
491 # import sys |
|
492 # import os |
|
493 |
|
494 # Each import is executed in its own try/except block, so if one module |
|
495 # fails to load the others will still be ok. |
|
496 |
|
497 import_mod |
|
498 |
|
499 #--------------------------------------------------------------------------- |
|
500 # Section: modules to import some functions from: 'from ... import ...' |
|
501 |
|
502 # List, one per line, the modules for which you want only to import some |
|
503 # functions. Give the module name first and then the name of functions to be |
|
504 # imported from that module. |
|
505 |
|
506 # Example: |
|
507 |
|
508 # import_some IPython.genutils timing timings |
|
509 # will produce internally the statement |
|
510 # from IPython.genutils import timing, timings |
|
511 |
|
512 # timing() and timings() are two IPython utilities for timing the execution of |
|
513 # your own functions, which you may find useful. Just commment out the above |
|
514 # line if you want to test them. |
|
515 |
|
516 # If you have more than one modules_some line, each gets its own try/except |
|
517 # block (like modules, see above). |
|
518 |
|
519 import_some |
|
520 |
|
521 #--------------------------------------------------------------------------- |
|
522 # Section: modules to import all from : 'from ... import *' |
|
523 |
|
524 # List (same syntax as import_mod above) those modules for which you want to |
|
525 # import all functions. Remember, this is a potentially dangerous thing to do, |
|
526 # since it is very easy to overwrite names of things you need. Use with |
|
527 # caution. |
|
528 |
|
529 # Example: |
|
530 # import_all sys os |
|
531 # will produce internally the statements |
|
532 # from sys import * |
|
533 # from os import * |
|
534 |
|
535 # As before, each will be called in a separate try/except block. |
|
536 |
|
537 import_all |
|
538 |
|
539 #--------------------------------------------------------------------------- |
|
540 # Section: Python code to execute. |
|
541 |
|
542 # Put here code to be explicitly executed (keep it simple!) |
|
543 # Put one line of python code per line. All whitespace is removed (this is a |
|
544 # feature, not a bug), so don't get fancy building loops here. |
|
545 # This is just for quick convenient creation of things you want available. |
|
546 |
|
547 # Example: |
|
548 # execute x = 1 |
|
549 # execute print 'hello world'; y = z = 'a' |
|
550 # will produce internally |
|
551 # x = 1 |
|
552 # print 'hello world'; y = z = 'a' |
|
553 # and each *line* (not each statement, we don't do python syntax parsing) is |
|
554 # executed in its own try/except block. |
|
555 |
|
556 execute |
|
557 |
|
558 # Note for the adventurous: you can use this to define your own names for the |
|
559 # magic functions, by playing some namespace tricks: |
|
560 |
|
561 # execute __IPYTHON__.magic_pf = __IPYTHON__.magic_profile |
|
562 |
|
563 # defines %pf as a new name for %profile. |
|
564 |
|
565 #--------------------------------------------------------------------------- |
|
566 # Section: Pyhton files to load and execute. |
|
567 |
|
568 # Put here the full names of files you want executed with execfile(file). If |
|
569 # you want complicated initialization, just write whatever you want in a |
|
570 # regular python file and load it from here. |
|
571 |
|
572 # Filenames defined here (which *must* include the extension) are searched for |
|
573 # through all of sys.path. Since IPython adds your .ipython directory to |
|
574 # sys.path, they can also be placed in your .ipython dir and will be |
|
575 # found. Otherwise (if you want to execute things not in .ipyton nor in |
|
576 # sys.path) give a full path (you can use ~, it gets expanded) |
|
577 |
|
578 # Example: |
|
579 # execfile file1.py ~/file2.py |
|
580 # will generate |
|
581 # execfile('file1.py') |
|
582 # execfile('_path_to_your_home/file2.py') |
|
583 |
|
584 # As before, each file gets its own try/except block. |
|
585 |
|
586 execfile |
|
587 |
|
588 # If you are feeling adventurous, you can even add functionality to IPython |
|
589 # through here. IPython works through a global variable called __ip which |
|
590 # exists at the time when these files are read. If you know what you are doing |
|
591 # (read the source) you can add functions to __ip in files loaded here. |
|
592 |
|
593 # The file example-magic.py contains a simple but correct example. Try it: |
|
594 |
|
595 # execfile example-magic.py |
|
596 |
|
597 # Look at the examples in IPython/iplib.py for more details on how these magic |
|
598 # functions need to process their arguments. |
|
599 |
|
600 #--------------------------------------------------------------------------- |
|
601 # Section: aliases for system shell commands |
|
602 |
|
603 # Here you can define your own names for system commands. The syntax is |
|
604 # similar to that of the builtin %alias function: |
|
605 |
|
606 # alias alias_name command_string |
|
607 |
|
608 # The resulting aliases are auto-generated magic functions (hence usable as |
|
609 # %alias_name) |
|
610 |
|
611 # For example: |
|
612 |
|
613 # alias myls ls -la |
|
614 |
|
615 # will define 'myls' as an alias for executing the system command 'ls -la'. |
|
616 # This allows you to customize IPython's environment to have the same aliases |
|
617 # you are accustomed to from your own shell. |
|
618 |
|
619 # You can also define aliases with parameters using %s specifiers (one per |
|
620 # parameter): |
|
621 |
|
622 # alias parts echo first %s second %s |
|
623 |
|
624 # will give you in IPython: |
|
625 # >>> %parts A B |
|
626 # first A second B |
|
627 |
|
628 # Use one 'alias' statement per alias you wish to define. |
|
629 |
|
630 # alias |
|
631 |
|
632 #************************* end of file <ipythonrc> ************************ |