Hi,<br><br>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...<br>
<br>* 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.<br>
<br>* 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&#39;s (the prompts) can&#39;t.  What I
mean by &quot;can&#39;t&quot; is that you can change IP.rc, but IPython&#39;s behavior
won&#39;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&#39;s behavior changes.  <br>
<br>Anyone who is paying attention at this point will think... &quot;ahh,
observers, notification, python&quot;, 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&#39;t work.  The only way we could use traits is if someone implemented
a pure Python version of traits (or a suitable subset).<br>
<br>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.<br><br>* We need to move away from the model of
&quot;IP holds the config for everything&quot; to each object holding and loading
its own config data.<br>
<br>* We need to de-couple configuration (the behavior of objects upon
creation) from notification/observation (how objects work together at
runtime).<br><br>With these things in mind, here is what I am thinking...<br><br>
All IPython classes will inherit from a number of base classes that provide the basic features we need also classes to have:<br><br>*
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.<br>
<br>* NotificationSource = an object that can notify other objects when its attributes change.  This is basically like a HasTraits.<br><br>Having
these 2 different subclasses should de-couple the question of
configuration from the question of notification/runtime attributes.<br>
<br>Thoughts?  Ideas? Feedback?<br><br>Cheers,<br><br>Brian