# preparser state for regexs

I would have expected the following to work:

reset()
import re

preparser(False)                         # preparser off else we have \\ instead of \
rx=re.compile(r".*(\sHun\s).*")          # in the regex

m = rx.match(r"The Attila the Hun Show") # Find "Hun" in "The Attila the Hun Show"
if m: print "found =>", m.group(1)       # 1 needs to be 1 not '1' here!

preparser(True)


In fact I get 'IndexError: no such group'. Using int(1) fixes the problem, but why? The preparser is off!

Even more curious the block works, as is, on every other evaluate! I tried moving the preparser(False) statement to before the import, but that makes no difference.

edit retag close merge delete

Sort by » oldest newest most voted

This works for me from the command line. In the notebook, it fails the first time and succeeds the second time. Indeed, having a notebook cell containing

preparser(False)
type(2)


fails the first time I evaluate it and succeeds the second time. This is what is supposed to happen, though. Consider this, from the command-line:

sage: preparser(False); type(2)


The first thing that happens is that the whole line gets preparsed, so "2" gets turned into "Integer(2)". Then the line gets evaluated, so it turns the preparser off and it returns the type of "Integer(2)", namely sage.rings.integer.Integer. I think that the same thing happens in each cell of the notebook: the whole thing gets preparsed before any of it is evaluated. So you need to put preparser(False) in a separate cell and evaluate it first.

more

No no no .. Something infinitly more diabolical! Experement with two cells as follows Cell one: preparser(False); print type(2) preparser(True); print type(2) Cell two: preparser(True); print type(2) preparser(False); print type(2) preparser(True) Also comment the last and see what happens. I'm totaly confused. I anycase, surely one should leave the preparser in the on state?

( 2012-08-30 17:33:16 +0200 )edit
1

I don't see anything wrong with these two cells. Any "preparser" commands cannot affect the current cell, since they haven't been evaluated yet. Once the cell has been evaluated (in its entirety), they affect any further cells, so for both of your cells, since they both end in "preparser(True)", the preparser is on all the time. If you remove the last "preparser(True)" from cell 2, then after evaluating that cell, the preparser will be off for any subsequent evaluations.

( 2012-08-30 18:48:07 +0200 )edit

You're missing some semicolons, by the way. Cell 1 should be preparser(False); print type(2); preparser(True); print type(2), and cell 2 should be preparser(True); print type(2); preparser(False); print type(2); preparser(True).

( 2012-08-30 18:49:07 +0200 )edit

I had a similar issue dealing with the preparser so I wrote an IPython extension which adds a cell magic %%noparse which disables the Sage preparser for the cell its applied to.

Save this code as noparse.py:

from IPython.core.magic import (Magics, magics_class, cell_magic)

import sage.repl.interpreter

@magics_class
class NoParseMagic(Magics):

@cell_magic
def noparse(self, line, cell):
"""
Use this cell magic to disable Sage preparsing in an IPython cell.
"""
sage.repl.interpreter._do_preparse = False
self.shell.run_cell(cell)
sage.repl.interpreter._do_preparse = True

ipython.register_magics(NoParseMagic)


If you like, you can copy this to .ipython/extensions/. Then in a Sage Jupyter notebook, you can run:

%load_ext noparse


to load the extension. Now the following works:

%%noparse
type(4)


which yields:

<type 'int'>


<type 'sage.rings.integer.Integer'>

more

I think this deserves to be added to the sage ipython kernel. Would you mind making a ticket for this?

( 2018-06-06 20:10:48 +0200 )edit

Thanks, I'll see if I can figure out how to do that later tonight.

( 2018-06-06 20:54:26 +0200 )edit
( 2018-06-07 02:20:30 +0200 )edit