[IPython-User] Advice on using a prefilter
Tue Aug 7 17:53:41 CDT 2012
OK, in case anyone is interested, here's what I ended up doing:
https://github.com/sympy/sympy/pull/1470. You can test it by checking
out that branch and running ./bin/isympy -i.
I ended up just monkey-patching run_cell, and checking the syntax
first before changing the input, so that SyntaxErrors will look OK to
We also have a bit of code there that automatically creates symbols
from undefined names. This currently uses an exception handler with
NameError, but I would love to use tokenize and a preparser with that
as well, as that would remove some subtle issues associated with the
current method. But I think I'll wait on the new API for that
(getting it wrong in this case can lead to far worse consequences, as
any "undefined name" would be converted).
On Tue, Aug 7, 2012 at 3:20 PM, Aaron Meurer <firstname.lastname@example.org> wrote:
> On Tue, Aug 7, 2012 at 3:08 PM, MinRK <email@example.com> wrote:
>> On Tue, Aug 7, 2012 at 1:55 PM, Thomas Kluyver <firstname.lastname@example.org> wrote:
>>> On 7 August 2012 21:35, Aaron Meurer <email@example.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
> 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.
>>> 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