[IPython-User] Advice on using a prefilter
Tue Aug 7 16:20:17 CDT 2012
On Tue, Aug 7, 2012 at 3:08 PM, MinRK <firstname.lastname@example.org> wrote:
> On Tue, Aug 7, 2012 at 1:55 PM, Thomas Kluyver <email@example.com> wrote:
>> On 7 August 2012 21:35, Aaron Meurer <firstname.lastname@example.org> 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
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.
> 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.
>> 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.
>> IPython-User mailing list
> IPython-User mailing list
More information about the IPython-User