[IPython-dev] Practices for .10 or .11 profile formats

Erik Tollerud erik.tollerud at gmail.com
Tue Jul 27 05:31:11 EDT 2010


Hi Fernando,

> Barring any unforeseen problems, we expect the 0.11 system for
> profiles to remain compatible from now on.

Good to know - the .11 system is a lot nicer than the previous ones anyway.

>We have a plan to make it
> easier for new projects to provide IPython profiles in *their own
> tree*, but the  syntax would be backwards-compatible.  Whereas now you
> say
>
> ipython -p profname
>
> we'd like to allow also (optionally, of course):
>
> ipython -p project:profname

Ooh, that's a neat idea - for now my plan was to include a script in
my project that would just bootstrap ipython (similar to how sympy
does it) depending on which (if any) version of IPython is found.  But
the scheme you have in mind would be much more elegant.


> That's a bug, plain and simple, sorry :)  For actual code, instead of
> exec_lines, I use this:
>
> c.Global.exec_files = ['extras.py']

I didn't realize that didn't increment the In[#] counter. Definitely
good to know that option is available, but I decided that if it was a
bug I should go hunting...

Trouble is, despite spending quite a bit of time rooting around in the
IPython.core, I can't seem to figure out where the input and output
cache's get populated and their counters incremented... It would be
possible, presumably, to run it like exec_files does for regular py
files and not use the ipython filtering and such, but that really
limits the usefulness of the profile... So is there some option some
where that can temporarily turn off the in/out caching (and presumably
that will also prevent the counter from incrementing)? And if not, is
there some obvious spot I missed where they get incremented that I
could try to figure out how it could be patched to prevent this
behavior?


-- 
Erik Tollerud



More information about the IPython-dev mailing list