[IPython-dev] Configuration system thoughts

Brian Granger ellisonbg.net@gmail....
Mon Jul 27 14:40:16 CDT 2009


Hi,

I am currently refactoring the IPython configuration system.  I thought this
would be a fairly straightforward task to move IPython to a single unified
config system with a new config file format.  But, it is turning out to be
quite massive undertaking.  I wanted to share some of my notes at this point
to generate discussion about this...

* Currently, we read assemble the main config objects in ipmaker.py and save
them as IP.rc which is a Struct.  From then on, IPython code can reference
the config variables using a notation like IP.rc.autocall, etc.  The logic
in ipmaker is super-messy and is one of the main config-y-things that needs
refactoring.

* But, this is not merely a configuration system, it is also a runtime
attribute system.  By this, I mean that the values in IP.rc are changed at
runtime by various parts of the code to change the behavior of the running
IPython.  Some attributes (like autocall) can be changed by modifying IP.rc
at runtime and other's (the prompts) can't.  What I mean by "can't" is that
you can change IP.rc, but IPython's behavior won't change.  An example of
this is that to get the prompts to change at runtime you need to  hack into
IP.outputcache.prompt1.  In other cases (like autocall), the relevant
IPython code always looks at IP.rc.autocall, so if it is changed, IPython's
behavior changes.

Anyone who is paying attention at this point will think... "ahh, observers,
notification, python", this sounds like enthought.traits!!!  Yes, traits
would definitely be one solution for dealing with this issue.  But, we
*really* want IPython to run on IronPython and Jython, so having traits as a
new dependency (it has a ~5000 line C-module) won't work.  The only way we
could use traits is if someone implemented a pure Python version of traits
(or a suitable subset).

When you think about plugging IPython into an actual GUI app, the need for
real observers/notifications increases only more.  I am sure that Gael will
agree.

* We need to move away from the model of "IP holds the config for
everything" to each object holding and loading its own config data.

* We need to de-couple configuration (the behavior of objects upon creation)
from notification/observation (how objects work together at runtime).

With these things in mind, here is what I am thinking...

All IPython classes will inherit from a number of base classes that provide
the basic features we need also classes to have:

* Configurable = an object that can be configured from the config files,
command line, and by passing in options.  Basically, this is an object that
has a super fancy __init__ logic (possibly not in __init__).  Each class
will declare where its default config file lives, what its command line
options are, etc.

* NotificationSource = an object that can notify other objects when its
attributes change.  This is basically like a HasTraits.

Having these 2 different subclasses should de-couple the question of
configuration from the question of notification/runtime attributes.

Thoughts?  Ideas? Feedback?

Cheers,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20090727/a2d6e547/attachment-0001.html 


More information about the IPython-dev mailing list