[IPython-dev] Curly braces stripped from magic input

Fernando Perez fperez.net at gmail.com
Mon Sep 2 00:29:12 EDT 2013

On Sat, Aug 31, 2013 at 11:35 AM, Greg Wilson <gvwilson at third-bit.com> wrote:
> On 2013-08-31 2:21 PM, Thomas Kluyver wrote:
> On 31 August 2013 10:07, Matt Davis <jiffyclub at gmail.com> wrote:
>> Is there any way around this, or do we just have to tell our students to
>> use \d{{3,4}} instead of valid regex?
> No, I don't think we currently have any way to disable this. You may prefer
> to declare regexes in regular Python code rather than within IPython magic
> commands.
> Hi Thomas,
> The point of this tool is to allow us to teach regular expressions *without*
> having to embed them in Python (or anything else) --- we've found they're
> easier for newcomers to digest if they can wrap their heads around
> \d+\s+\d+\b first, and then worry about raw strings, re.whatever, match
> objects, and so on.  What we have now lets us do this:
> %%regex a+b
> xyz
> aaabxx
> xabbbx
> xyzab
> xabxabx
> which is about as simple as it can get.  We can tell them to double the {}'s
> if we have to, but it seems weird not to have access to the original
> (unchomped) string...

Yes, it's weird and sub-optimal, and just a quirk of the historical
path followed by the implementation.  While we've cleaned up a LOT of
the magics machinery, there's always improvements to be done...

The culprit here is this line of code:


where we call var_expand *unconditionally* outside the magic object
itself.  So magics don't have a chance to know what the line before
expansion looked like...

I'd like to rewrite run_line_magic and run_cell_magic so they do even
less and hand over the input as quickly as possible to the magics
themselves. They can then decide whether to expand variables or not,
and would have access to the original buffer.

It's pretty straightforward to do, and would give us a clean and
simple solution to situations like this.

Fancy a PR, Greg? :)



More information about the IPython-dev mailing list