[IPython-dev] Add new commandline option from profile

MinRK benjaminrk@gmail....
Mon Jun 4 14:44:56 CDT 2012

On Mon, Jun 4, 2012 at 12:30 PM, Arnaud Gardelein <arnaud@oscopy.org> wrote:

> > What is your *actual* goal here, because I doubt that it is to
> > configure a transient object in your config file that will be deleted
> > immediately and not importable, which would be the case if defined in
> > a config file.
> I should had started from here... I'm working on oscopy ( oscopy.org ,
> latest features in experimental branch and -dev mailing list for doc).
> It started as a pure python app and became some time ago yet another
> ipython-based app during 0.10 era.
> After making the transition to 0.11, now I want to restore the support
> of commandline arguments that it had before the Switch (eg. batch,
> interactive, quiet...) before adding others.
> > If your goal is to make a particular class of yours configurable, you
> > can set its options in this way, and then the only thing you need to
> > do is pass the IPython instance's config object to your constructor:
> >
> > ipython --Foo.bar=True
> > In [1]: from IPython.config.configurable import Configurable
> > In [2]: from IPython.utils.traitlets import Bool
> > In [3]: class Foo(Configurable):
> >    ...:     bar = Bool(False, config=True)
> > In [4]: foo = Foo(config=get_ipython().config)
> > In [5]: foo.bar
> > Out[5]: True
> >
> Now I understand that processing of the configurable options shall be
> performed not from profile but from the app. I'm not sure of my
> understanding, does this means that at time of args processing it is not
> mandatory to have ipython's config loader is aware of the Foo class?

Correct, the config object is just a dict-like object, so:

config.Class.trait = foo

gives something very similar to:

{ 'Class' : {'trait' : foo } }

There is no checking on the config object.  The way the config system works
is we pass this object to the constructors of Configurables, and that is
where values, etc. are extracted based on class names, and validated with

For this reason, you can pass config for Foo at the command-line, and then
import (or even define) the Foo class at a later point.

> What I want to do is to add options to ipython when invoked with oscopy
> profile and those options appear when doing 'ipython --profile=ioscopy
> --help' as --term-title or --nosep do.

Is there a way to define aliases of --Foo.bar=True as -bar?

No, this is not possible.  Command-line args have been fully processed by
the time the config files are known.  It is impossible for profiles to
affect the Application's parsing of the command-line.  The only thing you
can do if you want to piggy-back on IPython's command-line args is to use
the full --Class.trait=foo form, which is passed entirely without

> I had a look
> at IPython/core/{interactiveshell,alias,application}.py without success,
> where are the manually defined flags? To define some for oscopy, shall
> BaseIPythonApplication be derived?

If you wanted to create your own entry point (ipython-oscopy), this would
be how you would go about it.  But any such subclassing will have no effect
on how the command `ipython` starts or parses args.


> Arnaud.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20120604/a878cabf/attachment-0001.html 

More information about the IPython-dev mailing list