In f-strings preparser sometimes misinterprets escaped characters (like \t) as "* BackslashOperator() *"

[maxale]

Steps To Reproduce

Example:

sage: print(f'{0:.1f}\tABC:')
0.0 * BackslashOperator() * tABC:

Expected Behavior

The same statement in Python prints the expected 0.0 ABC:.

Actual Behavior

Tabulation \t in the above example is incorrectly printed as * BackslashOperator() * t.

Additional Information

No response

Environment

- **OS**: Ubuntu 22.04.4 LTS
- **Sage Version**: 10.3.beta7

Checklist

• I have searched the existing issues for a bug report that matches the one I want to file, without success.
• I have read the documentation and troubleshoot guide

[Dhrumil07]

Hi, I am new to SageMath and want to contribute. Can I take up this issue? @maxale

[maxale]

@Dhrumil07 you don't need to ask me, please just do.

[Dhrumil07]

Hi @maxale
I think the issue with the above print statement is due to the use of 0:.1f format specification along with the f-strings.

We get the correct output on reversing the order in which we print. See the example below.

sage: print(f'ABC:\t{0:.1f}')
ABC:    0.0

Further, the desired output can be obtained by using the % format specifier (as used in older python versions)

sage: print(f'{"%.1f"%0}\tABC:')
0.0     ABC:

There seems to be an error with the use of value:.1f format specification with f-strings, whereas % format specifier works perfectly fine in all cases.

Also, the same print statement gives desired output in python and not in sage is questionable.
Are we using the same print() function in sage as used in python? Or is there any function overriding in sage based on some use-cases?

[nbruin]

Look up "preparser" in sage. It's a string processor that, when active, makes some replacements like \ -> BackslashOperator(). It has some rules built in to avoid doing that in places where it shouldn't, but it's not a full parser, so it's sometimes limited in what it can easily do. By the looks of it, format strings, which are a relatively recent addition to python, have some problems.

We've been able to avoid full parsing for a remarkable extent. It's worth a shot to see if format strings can be processed better with the machinery we have available, but given the complexity of them, I think there's a real chance we've now finally arrived at a point where our preprocessing needs a full parser in order to be completely correct.