Subsections

- Sample `ipythonrc` file
- Fine-tuning your prompt
  - Prompt examples
- IPython profiles

#
Customization

As we've already mentioned, IPython reads a configuration file which can be specified at the command line (`-rcfile`) or which by default is assumed to be called `ipythonrc`. Such a file is looked for in the current directory where IPython is started and then in your `IPYTHONDIR`, which allows you to have local configuration files for specific projects. In this section we will call these types of configuration files simply rcfiles (short for resource configuration file).

The syntax of an rcfile is one of key-value pairs separated by whitespace, one per line. Lines beginning with a `#` are ignored as comments, but comments can not be put on lines with data (the parser is fairly primitive). Note that these are not python files, and this is deliberate, because it allows us to do some things which would be quite tricky to implement if they were normal python files.

First, an rcfile can contain permanent default values for almost all command line options (except things like `-help` or `-Version`). Sec 5.2 contains a description of all command-line options. However, values you explicitly specify at the command line override the values defined in the rcfile.

Besides command line option values, the rcfile can specify values for certain extra special options which are not available at the command line. These options are briefly described below.

Each of these options may appear as many times as you need it in the file.

- [`include <file1> <file2> ...`:] you can name other rcfiles you want to recursively load up to 15 levels (don't use the `<>` brackets in your names!). This feature allows you to define a 'base' rcfile with general options and special-purpose files which can be loaded only when needed with particular configuration options. To make this more convenient, IPython accepts the `-profile <name>` option (abbreviates to `-p <name`>) `which` tells it to look for an rcfile named `ipythonrc-<name>`.
- [`import_mod <mod1> <mod2> ...`:] import modules with '`import` `<mod1>,<mod2>,...`'
- [`import_some <mod> <f1> <f2> ...`:] import functions with '`from <mod> import` `<f1>,<f2>,...`'
- [`import_all <mod1> <mod2> ...`:] for each module listed import functions with '`from <mod> import *`'
- [`execute <python code>`:] give any single-line python code to be executed.
- [`execfile <filename>`:] execute the python file given with an '`execfile(filename)`' command. Username expansion is performed on the given names. So if you need any amount of extra fancy customization that won't fit in any of the above 'canned' options, you can just put it in a separate python file and execute it.
- [`alias <alias_def>`:] this is equivalent to calling '`%alias <alias_def>`' at the IPython command line. This way, from within IPython you can do common system tasks without having to exit it or use the `!` escape. IPython isn't meant to be a shell replacement, but it is often very useful to be able to do things with files while testing code. This gives you the flexibility to have within IPython any aliases you may be used to under your normal system shell.

##
Sample `ipythonrc` file

The default rcfile, called `ipythonrc` and supplied in your `IPYTHONDIR` directory contains lots of comments on all of these options. We reproduce it here for reference:

    # -*- Mode: Shell-Script -*-  Not really, but shows comments correctly
    # $Id: ipythonrc 2156 2007-03-19 02:32:19Z fperez $

    #***************************************************************************
    #
    # Configuration file for IPython -- ipythonrc format
    #
    # ===========================================================
    # 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.
    # ===========================================================
    #
    # 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.

    # 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
    # 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
    # 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()

    # 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

    # 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.

    autoedit_syntax 0

    # 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
    # function %autoindent allows you to toggle it on/off at runtime.

    autoindent 1

    # Auto-magic. This gives you access to all the magic functions without having
    # to prepend them with an % sign. If you define a variable with the same name
    # as a magic function (say who=1), you will need to access the magic function
    # with % (%who in this example). However, if later you delete your variable
    # (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
    # function %color_info allows you to toggle this interactively for testing.

    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
    # the magic functions %Exit or %Quit you can force a direct exit, bypassing
    # 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

    # Which editor to use with the %edit command. If you leave this at 0, IPython
    # 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

    # 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

    # 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

    # 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

    # 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

    # 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

    # 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

    # 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

    #---------------------------------------------------------------------------
    # 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

    # 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

    # (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

    # defines %pf as a new name for %profile.

    #---------------------------------------------------------------------------
    # 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
    # similar to that of the builtin %alias function:

    # alias alias_name command_string

    # The resulting aliases are auto-generated magic functions (hence usable as
    # %alias_name)

    # 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:
    # >>> %parts A B
    # first A second B

    # Use one 'alias' statement per alias you wish to define.

    # alias

    #************************* end of file <ipythonrc> ************************

##
Fine-tuning your prompt

IPython's prompts can be customized using a syntax similar to that of the `bash` shell. Many of `bash`'s escapes are supported, as well as a few additional ones. We list them below:

\#
  the prompt/history count number. This escape is automatically wrapped in the coloring codes for the currently active color scheme.
\N
  the 'naked' prompt/history count number: this is just the number itself, without any coloring applied to it. This lets you produce numbered prompts with your own colors.
\D
  the prompt/history count, with the actual digits replaced by dots. Used mainly in continuation prompts (prompt_in2)
\w
  the current working directory
\W
  the basename of current working directory
\Xn
  where The current working directory, with `$HOME` replaced by `~`, and filtered out to contain only path elements
\Yn
  Similar to \Xn, but with the element included if it is `~` (this is similar to the behavior of the %cn escapes in `tcsh`)
\u
  the username of the current user
\$
  if the effective UID is 0, a #, otherwise a $
\h
  the hostname up to the first `.'
\H
  the hostname
\n
  a newline
\r
  a carriage return
\v
  IPython version string

In addition to these, ANSI color escapes can be insterted into the prompts, as `\C_ColorName`. The list of valid color names is: Black, Blue, Brown, Cyan, DarkGray, Green, LightBlue, LightCyan, LightGray, LightGreen, LightPurple, LightRed, NoColor, Normal, Purple, Red, White, Yellow.

Finally, IPython supports the evaluation of arbitrary expressions in your prompt string. The prompt strings are evaluated through the syntax of PEP 215, but basically you can use `$x.y` to expand the value of `x.y`, and for more complicated expressions you can use braces: `${foo()+x}` will call function `foo` and add to it the value of `x`, before putting the result into your prompt. For example, using
`prompt_in1 '${commands.getoutput("uptime")}\nIn [\#]: '`
will print the result of the uptime command on each prompt (assuming the `commands` module has been imported in your `ipythonrc` file).

### Prompt examples

The following options in an ipythonrc file will give you IPython's default prompts:

`prompt_in1 'In [\#]:'`
`prompt_in2 ' .\D.:'`
`prompt_out 'Out[\#]:'`

which look like this:

`In [1]: 1+2`
`Out[1]: 3`

`In [2]: for i in (1,2,3):`
`...: print i,`
`...:`
`1 2 3`

These will give you a very colorful prompt with path information:

`#prompt_in1 '\C_Red\u\C_Blue[\C_Cyan\Y1\C_Blue]\C_LightGreen\#>'`
`prompt_in2 ' ..\D>'`
`prompt_out '<\#>'`

which look like this:

`fperez[~/ipython]1>` `1+2`
`<1>` `3`
`fperez[~/ipython]2>` `for i in (1,2,3):`
`...>` `print i,`
`...>`
`1 2 3`

The following shows the usage of dynamic expression evaluation:

##
IPython profiles

As we already mentioned, IPython supports the `-profile` command-line option (see sec. 5.2). A profile is nothing more than a particular configuration file like your basic `ipythonrc` one, but with particular customizations for a specific purpose. When you start IPython with '`ipython -profile <name>`', it assumes that in your `IPYTHONDIR` there is a file called `ipythonrc-<name>`, and loads it instead of the normal `ipythonrc`.

This system allows you to maintain multiple configurations which load modules, set options, define functions, etc. suitable for different tasks and activate them in a very simple manner. In order to avoid having to repeat all of your basic options (common things that don't change such as your color preferences, for example), any profile can include another configuration file. The most common way to use profiles is then to have each one include your basic `ipythonrc` file as a starting point, and then add further customizations.

In sections 11 and 16 we discuss some particular profiles which come as part of the standard IPython distribution. You may also look in your `IPYTHONDIR` directory, any file whose name begins with `ipythonrc-` is a profile. You can use those as examples for further customizations to suit your own needs.