ipythonrc
632 lines
| 23.6 KiB
| text/plain
|
TextLexer
fperez
|
r0 | # -*- Mode: Shell-Script -*- Not really, but shows comments correctly | ||
fperez
|
r554 | # $Id: ipythonrc 2156 2007-03-19 02:32:19Z fperez $ | ||
fperez
|
r0 | |||
#*************************************************************************** | ||||
# | ||||
# Configuration file for IPython -- ipythonrc format | ||||
# | ||||
vivainio
|
r492 | # =========================================================== | ||
# Deprecation note: you should look into modifying ipy_user_conf.py (located | ||||
# in ~/.ipython or ~/_ipython, depending on your platform) instead, it's a | ||||
# more flexible and robust (and better supported!) configuration | ||||
# method. | ||||
# =========================================================== | ||||
# | ||||
fperez
|
r0 | # The format of this file is simply one of 'key value' lines. | ||
# Lines containing only whitespace at the beginning and then a # are ignored | ||||
# as comments. But comments can NOT be put on lines with data. | ||||
# The meaning and use of each key are explained below. | ||||
#--------------------------------------------------------------------------- | ||||
# Section: included files | ||||
# Put one or more *config* files (with the syntax of this file) you want to | ||||
# include. For keys with a unique value the outermost file has precedence. For | ||||
# keys with multiple values, they all get assembled into a list which then | ||||
# gets loaded by IPython. | ||||
# In this file, all lists of things should simply be space-separated. | ||||
# This allows you to build hierarchies of files which recursively load | ||||
# lower-level services. If this is your main ~/.ipython/ipythonrc file, you | ||||
# should only keep here basic things you always want available. Then you can | ||||
# include it in every other special-purpose config file you create. | ||||
include | ||||
#--------------------------------------------------------------------------- | ||||
# Section: startup setup | ||||
# These are mostly things which parallel a command line option of the same | ||||
# name. | ||||
# Keys in this section should only appear once. If any key from this section | ||||
# is encountered more than once, the last value remains, all earlier ones get | ||||
# discarded. | ||||
fperez
|
r84 | |||
# Automatic calling of callable objects. If set to 1 or 2, callable objects | ||||
# are automatically called when invoked at the command line, even if you don't | ||||
fperez
|
r0 | # type parentheses. IPython adds the parentheses for you. For example: | ||
#In [1]: str 45 | ||||
#------> str(45) | ||||
#Out[1]: '45' | ||||
# IPython reprints your line with '---->' indicating that it added | ||||
# parentheses. While this option is very convenient for interactive use, it | ||||
# may occasionally cause problems with objects which have side-effects if | ||||
fperez
|
r84 | # called unexpectedly. | ||
# The valid values for autocall are: | ||||
# autocall 0 -> disabled (you can toggle it at runtime with the %autocall magic) | ||||
# autocall 1 -> active, but do not apply if there are no arguments on the line. | ||||
# In this mode, you get: | ||||
#In [1]: callable | ||||
#Out[1]: <built-in function callable> | ||||
#In [2]: callable 'hello' | ||||
#------> callable('hello') | ||||
#Out[2]: False | ||||
# 2 -> Active always. Even if no arguments are present, the callable object | ||||
# is called: | ||||
#In [4]: callable | ||||
#------> callable() | ||||
fperez
|
r0 | |||
# Note that even with autocall off, you can still use '/' at the start of a | ||||
# line to treat the first argument on the command line as a function and add | ||||
# parentheses to it: | ||||
#In [8]: /str 43 | ||||
#------> str(43) | ||||
#Out[8]: '43' | ||||
autocall 1 | ||||
fperez
|
r57 | # Auto-edit syntax errors. When you use the %edit magic in ipython to edit | ||
# source code (see the 'editor' variable below), it is possible that you save | ||||
# a file with syntax errors in it. If this variable is true, IPython will ask | ||||
# you whether to re-open the editor immediately to correct such an error. | ||||
fperez
|
r294 | autoedit_syntax 0 | ||
fperez
|
r57 | |||
fperez
|
r0 | # Auto-indent. IPython can recognize lines ending in ':' and indent the next | ||
# line, while also un-indenting automatically after 'raise' or 'return'. | ||||
# This feature uses the readline library, so it will honor your ~/.inputrc | ||||
# configuration (or whatever file your INPUTRC variable points to). Adding | ||||
# the following lines to your .inputrc file can make indent/unindenting more | ||||
# convenient (M-i indents, M-u unindents): | ||||
# $if Python | ||||
# "\M-i": " " | ||||
# "\M-u": "\d\d\d\d" | ||||
# $endif | ||||
# The feature is potentially a bit dangerous, because it can cause problems | ||||
# with pasting of indented code (the pasted code gets re-indented on each | ||||
# line). But it's a huge time-saver when working interactively. The magic | ||||
fperez
|
r191 | # function %autoindent allows you to toggle it on/off at runtime. | ||
fperez
|
r0 | |||
autoindent 1 | ||||
# Auto-magic. This gives you access to all the magic functions without having | ||||
fperez
|
r191 | # to prepend them with an % sign. If you define a variable with the same name | ||
fperez
|
r0 | # as a magic function (say who=1), you will need to access the magic function | ||
fperez
|
r191 | # with % (%who in this example). However, if later you delete your variable | ||
fperez
|
r0 | # (del who), you'll recover the automagic calling form. | ||
# Considering that many magic functions provide a lot of shell-like | ||||
# functionality, automagic gives you something close to a full Python+system | ||||
# shell environment (and you can extend it further if you want). | ||||
automagic 1 | ||||
# Size of the output cache. After this many entries are stored, the cache will | ||||
# get flushed. Depending on the size of your intermediate calculations, you | ||||
# may have memory problems if you make it too big, since keeping things in the | ||||
# cache prevents Python from reclaiming the memory for old results. Experiment | ||||
# with a value that works well for you. | ||||
# If you choose cache_size 0 IPython will revert to python's regular >>> | ||||
# unnumbered prompt. You will still have _, __ and ___ for your last three | ||||
# results, but that will be it. No dynamic _1, _2, etc. will be created. If | ||||
# you are running on a slow machine or with very limited memory, this may | ||||
# help. | ||||
cache_size 1000 | ||||
# Classic mode: Setting 'classic 1' you lose many of IPython niceties, | ||||
# but that's your choice! Classic 1 -> same as IPython -classic. | ||||
# Note that this is _not_ the normal python interpreter, it's simply | ||||
# IPython emulating most of the classic interpreter's behavior. | ||||
classic 0 | ||||
# colors - Coloring option for prompts and traceback printouts. | ||||
# Currently available schemes: NoColor, Linux, LightBG. | ||||
# This option allows coloring the prompts and traceback printouts. This | ||||
# requires a terminal which can properly handle color escape sequences. If you | ||||
# are having problems with this, use the NoColor scheme (uses no color escapes | ||||
# at all). | ||||
# The Linux option works well in linux console type environments: dark | ||||
# background with light fonts. | ||||
# LightBG is similar to Linux but swaps dark/light colors to be more readable | ||||
# in light background terminals. | ||||
# keep uncommented only the one you want: | ||||
colors Linux | ||||
#colors LightBG | ||||
#colors NoColor | ||||
######################## | ||||
# Note to Windows users | ||||
# | ||||
# Color and readline support is avaialble to Windows users via Gary Bishop's | ||||
# readline library. You can find Gary's tools at | ||||
# http://sourceforge.net/projects/uncpythontools. | ||||
# Note that his readline module requires in turn the ctypes library, available | ||||
# at http://starship.python.net/crew/theller/ctypes. | ||||
######################## | ||||
# color_info: IPython can display information about objects via a set of | ||||
# functions, and optionally can use colors for this, syntax highlighting | ||||
# source code and various other elements. This information is passed through a | ||||
# pager (it defaults to 'less' if $PAGER is not set). | ||||
# If your pager has problems, try to setting it to properly handle escapes | ||||
# (see the less manpage for detail), or disable this option. The magic | ||||
fperez
|
r191 | # function %color_info allows you to toggle this interactively for testing. | ||
fperez
|
r0 | |||
color_info 1 | ||||
# confirm_exit: set to 1 if you want IPython to confirm when you try to exit | ||||
# with an EOF (Control-d in Unix, Control-Z/Enter in Windows). Note that using | ||||
fperez
|
r191 | # the magic functions %Exit or %Quit you can force a direct exit, bypassing | ||
fperez
|
r0 | # any confirmation. | ||
confirm_exit 1 | ||||
# Use deep_reload() as a substitute for reload() by default. deep_reload() is | ||||
# still available as dreload() and appears as a builtin. | ||||
deep_reload 0 | ||||
fperez
|
r191 | # Which editor to use with the %edit command. If you leave this at 0, IPython | ||
fperez
|
r0 | # will honor your EDITOR environment variable. Since this editor is invoked on | ||
# the fly by ipython and is meant for editing small code snippets, you may | ||||
# want to use a small, lightweight editor here. | ||||
# For Emacs users, setting up your Emacs server properly as described in the | ||||
# manual is a good idea. An alternative is to use jed, a very light editor | ||||
# with much of the feel of Emacs (though not as powerful for heavy-duty work). | ||||
editor 0 | ||||
# log 1 -> same as ipython -log. This automatically logs to ./ipython.log | ||||
log 0 | ||||
# Same as ipython -Logfile YourLogfileName. | ||||
# Don't use with log 1 (use one or the other) | ||||
logfile '' | ||||
# banner 0 -> same as ipython -nobanner | ||||
banner 1 | ||||
# messages 0 -> same as ipython -nomessages | ||||
messages 1 | ||||
# Automatically call the pdb debugger after every uncaught exception. If you | ||||
# are used to debugging using pdb, this puts you automatically inside of it | ||||
# after any call (either in IPython or in code called by it) which triggers an | ||||
# exception which goes uncaught. | ||||
pdb 0 | ||||
# Enable the pprint module for printing. pprint tends to give a more readable | ||||
# display (than print) for complex nested data structures. | ||||
pprint 1 | ||||
# Prompt strings | ||||
# Most bash-like escapes can be used to customize IPython's prompts, as well as | ||||
# a few additional ones which are IPython-specific. All valid prompt escapes | ||||
# are described in detail in the Customization section of the IPython HTML/PDF | ||||
# manual. | ||||
# Use \# to represent the current prompt number, and quote them to protect | ||||
# spaces. | ||||
prompt_in1 'In [\#]: ' | ||||
# \D is replaced by as many dots as there are digits in the | ||||
# current value of \#. | ||||
prompt_in2 ' .\D.: ' | ||||
prompt_out 'Out[\#]: ' | ||||
# Select whether to left-pad the output prompts to match the length of the | ||||
# input ones. This allows you for example to use a simple '>' as an output | ||||
# prompt, and yet have the output line up with the input. If set to false, | ||||
# the output prompts will be unpadded (flush left). | ||||
prompts_pad_left 1 | ||||
fperez
|
r554 | # Pylab support: when ipython is started with the -pylab switch, by default it | ||
# executes 'from matplotlib.pylab import *'. Set this variable to false if you | ||||
# want to disable this behavior. | ||||
# For details on pylab, see the matplotlib website: | ||||
# http://matplotlib.sf.net | ||||
pylab_import_all 1 | ||||
fperez
|
r0 | # quick 1 -> same as ipython -quick | ||
quick 0 | ||||
# Use the readline library (1) or not (0). Most users will want this on, but | ||||
# if you experience strange problems with line management (mainly when using | ||||
# IPython inside Emacs buffers) you may try disabling it. Not having it on | ||||
# prevents you from getting command history with the arrow keys, searching and | ||||
# name completion using TAB. | ||||
readline 1 | ||||
# Screen Length: number of lines of your screen. This is used to control | ||||
# printing of very long strings. Strings longer than this number of lines will | ||||
# be paged with the less command instead of directly printed. | ||||
# The default value for this is 0, which means IPython will auto-detect your | ||||
# screen size every time it needs to print. If for some reason this isn't | ||||
# working well (it needs curses support), specify it yourself. Otherwise don't | ||||
# change the default. | ||||
screen_length 0 | ||||
# Prompt separators for input and output. | ||||
# Use \n for newline explicitly, without quotes. | ||||
# Use 0 (like at the cmd line) to turn off a given separator. | ||||
# The structure of prompt printing is: | ||||
# (SeparateIn)Input.... | ||||
# (SeparateOut)Output... | ||||
# (SeparateOut2), # that is, no newline is printed after Out2 | ||||
# By choosing these you can organize your output any way you want. | ||||
separate_in \n | ||||
separate_out 0 | ||||
separate_out2 0 | ||||
# 'nosep 1' is a shorthand for '-SeparateIn 0 -SeparateOut 0 -SeparateOut2 0'. | ||||
# Simply removes all input/output separators, overriding the choices above. | ||||
nosep 0 | ||||
fperez
|
r41 | # Wildcard searches - IPython has a system for searching names using | ||
# shell-like wildcards; type %psearch? for details. This variables sets | ||||
# whether by default such searches should be case sensitive or not. You can | ||||
# always override the default at the system command line or the IPython | ||||
# prompt. | ||||
wildcards_case_sensitive 1 | ||||
fperez
|
r299 | # Object information: at what level of detail to display the string form of an | ||
# object. If set to 0, ipython will compute the string form of any object X, | ||||
# by calling str(X), when X? is typed. If set to 1, str(X) will only be | ||||
# computed when X?? is given, and if set to 2 or higher, it will never be | ||||
# computed (there is no X??? level of detail). This is mostly of use to | ||||
# people who frequently manipulate objects whose string representation is | ||||
# extremely expensive to compute. | ||||
object_info_string_level 0 | ||||
fperez
|
r0 | # xmode - Exception reporting mode. | ||
# Valid modes: Plain, Context and Verbose. | ||||
# Plain: similar to python's normal traceback printing. | ||||
# Context: prints 5 lines of context source code around each line in the | ||||
# traceback. | ||||
# Verbose: similar to Context, but additionally prints the variables currently | ||||
# visible where the exception happened (shortening their strings if too | ||||
# long). This can potentially be very slow, if you happen to have a huge data | ||||
# structure whose string representation is complex to compute. Your computer | ||||
# may appear to freeze for a while with cpu usage at 100%. If this occurs, you | ||||
# can cancel the traceback with Ctrl-C (maybe hitting it more than once). | ||||
#xmode Plain | ||||
xmode Context | ||||
#xmode Verbose | ||||
# multi_line_specials: if true, allow magics, aliases and shell escapes (via | ||||
# !cmd) to be used in multi-line input (like for loops). For example, if you | ||||
# have this active, the following is valid in IPython: | ||||
# | ||||
#In [17]: for i in range(3): | ||||
# ....: mkdir $i | ||||
# ....: !touch $i/hello | ||||
# ....: ls -l $i | ||||
multi_line_specials 1 | ||||
fptest
|
r418 | |||
# System calls: When IPython makes system calls (e.g. via special syntax like | ||||
# !cmd or !!cmd, or magics like %sc or %sx), it can print the command it is | ||||
# executing to standard output, prefixed by a header string. | ||||
system_header "IPython system call: " | ||||
system_verbose 1 | ||||
fperez
|
r91 | # wxversion: request a specific wxPython version (used for -wthread) | ||
# Set this to the value of wxPython you want to use, but note that this | ||||
# feature requires you to have the wxversion Python module to work. If you | ||||
# don't have the wxversion module (try 'import wxversion' at the prompt to | ||||
# check) or simply want to leave the system to pick up the default, leave this | ||||
# variable at 0. | ||||
wxversion 0 | ||||
fperez
|
r0 | #--------------------------------------------------------------------------- | ||
# Section: Readline configuration (readline is not available for MS-Windows) | ||||
# This is done via the following options: | ||||
# (i) readline_parse_and_bind: this option can appear as many times as you | ||||
# want, each time defining a string to be executed via a | ||||
# readline.parse_and_bind() command. The syntax for valid commands of this | ||||
# kind can be found by reading the documentation for the GNU readline library, | ||||
# as these commands are of the kind which readline accepts in its | ||||
# configuration file. | ||||
# The TAB key can be used to complete names at the command line in one of two | ||||
# ways: 'complete' and 'menu-complete'. The difference is that 'complete' only | ||||
# completes as much as possible while 'menu-complete' cycles through all | ||||
# possible completions. Leave the one you prefer uncommented. | ||||
readline_parse_and_bind tab: complete | ||||
#readline_parse_and_bind tab: menu-complete | ||||
# This binds Control-l to printing the list of all possible completions when | ||||
# there is more than one (what 'complete' does when hitting TAB twice, or at | ||||
# the first TAB if show-all-if-ambiguous is on) | ||||
readline_parse_and_bind "\C-l": possible-completions | ||||
# This forces readline to automatically print the above list when tab | ||||
# completion is set to 'complete'. You can still get this list manually by | ||||
# using the key bound to 'possible-completions' (Control-l by default) or by | ||||
# hitting TAB twice. Turning this on makes the printing happen at the first | ||||
# TAB. | ||||
readline_parse_and_bind set show-all-if-ambiguous on | ||||
# If you have TAB set to complete names, you can rebind any key (Control-o by | ||||
# default) to insert a true TAB character. | ||||
readline_parse_and_bind "\C-o": tab-insert | ||||
# These commands allow you to indent/unindent easily, with the 4-space | ||||
# convention of the Python coding standards. Since IPython's internal | ||||
# auto-indent system also uses 4 spaces, you should not change the number of | ||||
# spaces in the code below. | ||||
readline_parse_and_bind "\M-i": " " | ||||
readline_parse_and_bind "\M-o": "\d\d\d\d" | ||||
readline_parse_and_bind "\M-I": "\d\d\d\d" | ||||
# Bindings for incremental searches in the history. These searches use the | ||||
# string typed so far on the command line and search anything in the previous | ||||
# input history containing them. | ||||
readline_parse_and_bind "\C-r": reverse-search-history | ||||
readline_parse_and_bind "\C-s": forward-search-history | ||||
# Bindings for completing the current line in the history of previous | ||||
# commands. This allows you to recall any previous command by typing its first | ||||
# few letters and hitting Control-p, bypassing all intermediate commands which | ||||
# may be in the history (much faster than hitting up-arrow 50 times!) | ||||
readline_parse_and_bind "\C-p": history-search-backward | ||||
readline_parse_and_bind "\C-n": history-search-forward | ||||
# I also like to have the same functionality on the plain arrow keys. If you'd | ||||
# rather have the arrows use all the history (and not just match what you've | ||||
# typed so far), comment out or delete the next two lines. | ||||
readline_parse_and_bind "\e[A": history-search-backward | ||||
readline_parse_and_bind "\e[B": history-search-forward | ||||
tzanko
|
r1 | # These are typically on by default under *nix, but not win32. | ||
readline_parse_and_bind "\C-k": kill-line | ||||
readline_parse_and_bind "\C-u": unix-line-discard | ||||
fperez
|
r0 | # (ii) readline_remove_delims: a string of characters to be removed from the | ||
# default word-delimiters list used by readline, so that completions may be | ||||
# performed on strings which contain them. | ||||
readline_remove_delims -/~ | ||||
# (iii) readline_merge_completions: whether to merge the result of all | ||||
# possible completions or not. If true, IPython will complete filenames, | ||||
# python names and aliases and return all possible completions. If you set it | ||||
# to false, each completer is used at a time, and only if it doesn't return | ||||
# any completions is the next one used. | ||||
# The default order is: [python_matches, file_matches, alias_matches] | ||||
readline_merge_completions 1 | ||||
# (iv) readline_omit__names: normally hitting <tab> after a '.' in a name | ||||
# will complete all attributes of an object, including all the special methods | ||||
# whose names start with single or double underscores (like __getitem__ or | ||||
# __class__). | ||||
# This variable allows you to control this completion behavior: | ||||
# readline_omit__names 1 -> completion will omit showing any names starting | ||||
# with two __, but it will still show names starting with one _. | ||||
# readline_omit__names 2 -> completion will omit all names beginning with one | ||||
# _ (which obviously means filtering out the double __ ones). | ||||
# Even when this option is set, you can still see those names by explicitly | ||||
# typing a _ after the period and hitting <tab>: 'name._<tab>' will always | ||||
# complete attribute names starting with '_'. | ||||
# This option is off by default so that new users see all attributes of any | ||||
# objects they are dealing with. | ||||
readline_omit__names 0 | ||||
#--------------------------------------------------------------------------- | ||||
# Section: modules to be loaded with 'import ...' | ||||
# List, separated by spaces, the names of the modules you want to import | ||||
# Example: | ||||
# import_mod sys os | ||||
# will produce internally the statements | ||||
# import sys | ||||
# import os | ||||
# Each import is executed in its own try/except block, so if one module | ||||
# fails to load the others will still be ok. | ||||
import_mod | ||||
#--------------------------------------------------------------------------- | ||||
# Section: modules to import some functions from: 'from ... import ...' | ||||
# List, one per line, the modules for which you want only to import some | ||||
# functions. Give the module name first and then the name of functions to be | ||||
# imported from that module. | ||||
# Example: | ||||
# import_some IPython.genutils timing timings | ||||
# will produce internally the statement | ||||
# from IPython.genutils import timing, timings | ||||
# timing() and timings() are two IPython utilities for timing the execution of | ||||
# your own functions, which you may find useful. Just commment out the above | ||||
# line if you want to test them. | ||||
# If you have more than one modules_some line, each gets its own try/except | ||||
# block (like modules, see above). | ||||
import_some | ||||
#--------------------------------------------------------------------------- | ||||
# Section: modules to import all from : 'from ... import *' | ||||
# List (same syntax as import_mod above) those modules for which you want to | ||||
# import all functions. Remember, this is a potentially dangerous thing to do, | ||||
# since it is very easy to overwrite names of things you need. Use with | ||||
# caution. | ||||
# Example: | ||||
# import_all sys os | ||||
# will produce internally the statements | ||||
# from sys import * | ||||
# from os import * | ||||
# As before, each will be called in a separate try/except block. | ||||
import_all | ||||
#--------------------------------------------------------------------------- | ||||
# Section: Python code to execute. | ||||
# Put here code to be explicitly executed (keep it simple!) | ||||
# Put one line of python code per line. All whitespace is removed (this is a | ||||
# feature, not a bug), so don't get fancy building loops here. | ||||
# This is just for quick convenient creation of things you want available. | ||||
# Example: | ||||
# execute x = 1 | ||||
# execute print 'hello world'; y = z = 'a' | ||||
# will produce internally | ||||
# x = 1 | ||||
# print 'hello world'; y = z = 'a' | ||||
# and each *line* (not each statement, we don't do python syntax parsing) is | ||||
# executed in its own try/except block. | ||||
execute | ||||
# Note for the adventurous: you can use this to define your own names for the | ||||
# magic functions, by playing some namespace tricks: | ||||
# execute __IPYTHON__.magic_pf = __IPYTHON__.magic_profile | ||||
fperez
|
r191 | # defines %pf as a new name for %profile. | ||
fperez
|
r0 | |||
#--------------------------------------------------------------------------- | ||||
# Section: Pyhton files to load and execute. | ||||
# Put here the full names of files you want executed with execfile(file). If | ||||
# you want complicated initialization, just write whatever you want in a | ||||
# regular python file and load it from here. | ||||
# Filenames defined here (which *must* include the extension) are searched for | ||||
# through all of sys.path. Since IPython adds your .ipython directory to | ||||
# sys.path, they can also be placed in your .ipython dir and will be | ||||
# found. Otherwise (if you want to execute things not in .ipyton nor in | ||||
# sys.path) give a full path (you can use ~, it gets expanded) | ||||
# Example: | ||||
# execfile file1.py ~/file2.py | ||||
# will generate | ||||
# execfile('file1.py') | ||||
# execfile('_path_to_your_home/file2.py') | ||||
# As before, each file gets its own try/except block. | ||||
execfile | ||||
# If you are feeling adventurous, you can even add functionality to IPython | ||||
# through here. IPython works through a global variable called __ip which | ||||
# exists at the time when these files are read. If you know what you are doing | ||||
# (read the source) you can add functions to __ip in files loaded here. | ||||
# The file example-magic.py contains a simple but correct example. Try it: | ||||
# execfile example-magic.py | ||||
# Look at the examples in IPython/iplib.py for more details on how these magic | ||||
# functions need to process their arguments. | ||||
#--------------------------------------------------------------------------- | ||||
# Section: aliases for system shell commands | ||||
# Here you can define your own names for system commands. The syntax is | ||||
fperez
|
r191 | # similar to that of the builtin %alias function: | ||
fperez
|
r0 | |||
# alias alias_name command_string | ||||
# The resulting aliases are auto-generated magic functions (hence usable as | ||||
fperez
|
r191 | # %alias_name) | ||
fperez
|
r0 | |||
# For example: | ||||
# alias myls ls -la | ||||
# will define 'myls' as an alias for executing the system command 'ls -la'. | ||||
# This allows you to customize IPython's environment to have the same aliases | ||||
# you are accustomed to from your own shell. | ||||
# You can also define aliases with parameters using %s specifiers (one per | ||||
# parameter): | ||||
# alias parts echo first %s second %s | ||||
# will give you in IPython: | ||||
fperez
|
r191 | # >>> %parts A B | ||
fperez
|
r0 | # first A second B | ||
# Use one 'alias' statement per alias you wish to define. | ||||
# alias | ||||
#************************* end of file <ipythonrc> ************************ | ||||