#11542: Fix preparse_file to prevent constants from being assigned to
-------------------------------------+-------------------------------------
Reporter: nbruin | Owner: was
Type: defect | Status: new
Priority: major | Milestone: sage-6.4
Component: user interface | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/11542 | a8c10952b8ca987cd5c8623cbbaf857ee79bbecc
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Changes (by gagern):
* commit: => a8c10952b8ca987cd5c8623cbbaf857ee79bbecc
Comment:
Quoting from the commit message of the commit I just pushed:
> The core idea is to replace numeric literals not directly with the
corresponding variable name, but instead with a formatting placeholder
similar to those used for string literals and comments. That way we can
substitute different things for different applications: for syntax checks
we substitute real python numeric literals, namely the literal `1`. For
compilation and execution, we plug in the variable names. This approach
was suggested by Robert Bradshaw.
>
> This change deliberately breaks compatibility with regard to the values
returned by `preparse_numeric_literals(code, extract=True)` and
`extract_numeric_literals`. Where the first element of the returned tuple
used to contain variable names, it now contains formatting termplates.
There are also some slight deviations regarding spaces added after raw
Python numeric literals. It is assumed that no user code will rely on any
of this functionality, except indirectly via `preparse_file`.
>
> This change might incur some performance penalty since the Python code
has to be parsed twice. On the other hand, there are some situations
where performance should become better. We avoid extracting string
literals twice, in `preparse_file` and preparse. We also avoid running
the preparser on the numeric literals. The latter apparently was a
limiting factor for the number of assignments which could be placed in the
first row. Perhaps that limit no longer applies now, and should be
removed in a subsequent commit.
Please let me know if you consider my approach of breaking the API
unsuitable, and if I should follow proper deprecation procedures instead.
If so, getting a clean interface for all of this might require several
years: I'd first introduce a keyword argument to
`extract_numeric_literals` and deprecate calls without that, then I'd make
code always follow the new behavior and deprecate calls with that
argument. Two deprecation steps, means two years minimum.
Please also let me know what you thing of ''always'' placing all
assignments into the first line, now that doing so should be possible
without trouble from the preparser.
I'll not be able to work on this for the next few weeks, or even respond
to input. If someone else wants to take this up and push it through
review, be my guest. Otherwise I'll request review at some point next
month.
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=a8c10952b8ca987cd5c8623cbbaf857ee79bbecc
a8c1095]||{{{preparse_file: trigger SyntaxError on assignment to numeric
literal.}}}||
--
Ticket URL: <http://trac.sagemath.org/ticket/11542#comment:10>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
