[IPython-User] Advice on using a prefilter

Aaron Meurer asmeurer@gmail....
Tue Aug 7 16:20:17 CDT 2012

On Tue, Aug 7, 2012 at 3:08 PM, MinRK <benjaminrk@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 1:55 PM, Thomas Kluyver <takowl@gmail.com> wrote:
>> On 7 August 2012 21:35, Aaron Meurer <asmeurer@gmail.com> wrote:
>> > Is monkey-patching run_cell going to be as evil as it sounds?
>> It's going to be more evil than it sounds. run_cell is pretty much the
>> core function of IPython, and we really don't want people
>> monkeypatching it.
> The following in one of my startup files:
> shell = get_ipython()
> old_run_cell = shell.run_cell
> def transform(cell):
>     return u'\n'.join([cell, 'print "hello!"'])
> def new_run_cell(cell, *args, **kwargs):
>     new_cell = transform(cell)
>     return old_run_cell(new_cell, *args, **kwargs)
> shell.run_cell = new_run_cell
> Lets me trivially do transforms to complete cells, without actually changing
> anything *inside* run_cell.  This doesn't seem too bad to me, at least as a
> temporary measure while IPython gets itself an official API for cell-level
> transforms.

Right.  This is pretty much exactly what I was going to do.
Preprocess the text, then send it to the actual run_cell.  I can
personally only see subtle difficulties with this.  In particular, I
have to make a choice:

1. If there is a SyntaxError, then the user will see the transformed
cell in the traceback.

2. Fallback to the original cell if there is a SyntaxError.  This will
mean that the transformation won't happen if there is magic (like
%timeit), which might also be confusing.  But then again, some magic
should not be transformed in the way I plan to do (like %run).  So I
guess this is actually a good thing for now.  There's something to
consider in the new API: I might want the transformation to happen to
arguments of magic functions, but only those for which the arguments
are valid Python code.

Aaron Meurer

> If Prefilter/InputSplitter were not already on Thomas' chopping block, then
> I would actually propose that we add a simple hook that's a list of
> callables to run on the cell at the top of run_cell. But since Thomas
> already plans to clean up the relevant APIs, it makes more sense to include
> this as one of the use cases to consider while writing the new code.
> -MinRK
>> I think for now your best bet is to use the existing prefilter API,
>> and accept that it doesn't work for multiline cells yet.
>> Issue 1491 is about this. I've just bumped the priority to high,
>> milestoned it for the next release and assigned myself. I'll do my
>> utmost to look into this in the next few days.
>> https://github.com/ipython/ipython/issues/1491
>> Thanks,
>> Thomas
>> _______________________________________________
>> IPython-User mailing list
>> IPython-User@scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-user
> _______________________________________________
> IPython-User mailing list
> IPython-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-user

More information about the IPython-User mailing list