x!=eval("%s"%x)...

[Emmanuel Charpentier]

The recent evolution of Sage seems to break the print(eval(read)) equivalence :

sage: var("a0, a1") (a0, a1) sage: "%s"%a0^a1 'a0^a1'

So far so good. But :

sage: eval("%s"%a0^a1) --------------------------------------------------------------------------- RuntimeError Traceback (most recent call last) Cell In[54], line 1 ----> 1 eval("%s"%a0**a1) File <string>:1 File /usr/local/sage-10/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/sage/structure/element.pyx:952, in sage.structure.element.Element.__xor__ (build/cythonized/sage/structure/element.c:16917)() 950 951 def __xor__(self, right): --> 952 raise RuntimeError("Use ** for exponentiation, not '^', which means xor\n" 953 "in Python, and has the wrong precedence.") 954 RuntimeError: Use ** for exponentiation, not '^', which means xor in Python, and has the wrong precedence.

But, inconsistently :

sage: "%s"%a0**a1 'a0^a1'

In other words, Sage insists for reading x**y and for printing x^y.

Unless I’m missing something, these choices are inconsistent.

Should I file an issue ?

​

[Nils Bruin]

This is not recent. Sage uses the preparser by default, so the choice to print a^b as such is consistent with what is accepted at the prompt.

We have this:

sage: var("a,b")
(a, b)
sage: E = a^b
sage: bool(E == eval(preparse(str(E))))
True

or, if you prefer,

sage: sage_eval(str(E),globals())
a^b

Python is now much more well-known and accepted than when sage started out, so perhaps the preparser is now less necessary for people to accept it as a computer algebra language, but the legacy of having the preparser (and, most importantly, "^" for exponentiation) is now set in sage and aligns it with nearly all computer algebra systems. I don't think it will be doable to abandon that in order to improve compatibility with the rest of python (in notation).

By the way, the "%" operator is not the preferred way to format strings. Using "{}".format(x) is now preferred in python. You have access to more formatting features than through the "%" mechanism.