<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> IPython.  Some attributes (like autocall) can be changed by modifying IP.rc<br>
> at runtime and other's (the prompts) can't.  What I mean by "can't" is that<br>
> you can change IP.rc, but IPython's behavior won't change.  An example of<br>
> this is that to get the prompts to change at runtime you need to  hack into<br>
> IP.outputcache.prompt1.  In other cases (like autocall), the relevant<br>
> IPython code always looks at IP.rc.autocall, so if it is changed, IPython's<br>
> behavior changes.<br>
<br>
</div>Many of these problems could be fixed by fixing stuff like prompts to<br>
actually look at the config variable every time. Since it needs some<br>
"computation" every time, you can remember the value of previous<br>
invocation and do the calculation only if it has changed.<br>
<font color="#888888"></font></blockquote><div><br>Yes, definitely.  However, the current approach of having IP.rc hold the runtime value for *everything* means that everything is tightly coupled to IP.  That is what we have to break.  My vision is that all objects will hold their own runtime state.  Thus the prompt objects will hold the values of the prompt strings.  We will then have an API that allows other parts of the code base to modify those values.  But all of that will be completey independent of IP.<br>
<br>Brian<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
--<br>
Ville M. Vainio<br>
<a href="http://tinyurl.com/vainio" target="_blank">http://tinyurl.com/vainio</a><br>
</font></blockquote></div><br>