You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
f-string evaluation of conditional expressions with != operator seems to fail #129093
I expected that the output of print(f'{True != True=}') would be True != True=False.
According to docs, "[t]o display both the expression text and its value after evaluation, (useful in debugging), an equal sign '=' may be added after the expression". So print(f'{True != True=}') fails because the expression text is not fully displayed -- even "=" is omitted.
Sorry if this is a duplicate -- I was not able to find any other report here and in Cython issue tracker.
Yeah! I think that any conditional expression containing != behaves in the same manner -- whatever the result of evaluating the expression is.
Yes, I was just trying to point out that the True in the last evaluated expression comes not from the source code of the expression, but rather the value. Which is also why I removed the spaces around !=.
So it does evaluate 1 != 0, but instead of outputting a constant 1!=0= (as it should) it outputs just 1. I suspect something is looking for the ! that introduces conversion specifiers and gets confused by the ! in the != operator.
A ! inside a string literal does work correctly though:
I suspect something is looking for the ! that introduces conversion specifiers and gets confused by the ! in the != operator.
while #124363, as long as I understand, is related to raw strings and escape characters, which is not the case here.
The problem here seems to be that the expression text is printed up to ! while the expression itself is correctly evaluated, such as in the following example:
Activity
StanFromIreland commentedon Jan 20, 2025
Tested on Windows 11 with 3.13 and same bug.
ericvsmith commentedon Jan 20, 2025
Also:
JD-Veiga commentedon Jan 20, 2025
Yeah! I think that any conditional expression containing != behaves in the same manner -- whatever the result of evaluating the expression is.
ericvsmith commentedon Jan 20, 2025
Yes, I was just trying to point out that the
Truein the last evaluated expression comes not from the source code of the expression, but rather the value. Which is also why I removed the spaces around!=.JelleZijlstra commentedon Jan 20, 2025
The AST looks like this:
So it does evaluate
1 != 0, but instead of outputting a constant1!=0=(as it should) it outputs just1. I suspect something is looking for the!that introduces conversion specifiers and gets confused by the!in the!=operator.A
!inside a string literal does work correctly though:sobolevn commentedon Jan 20, 2025
This is a parsing issue:
tomasr8 commentedon Jan 20, 2025
This seems to fix it (with
test_fstringpassing), but I don't fully understand why yet:I'll try to add some tests and perhaps open a PR tomorrow
picnixz commentedon Jan 21, 2025
Could this be related to #124363?
JD-Veiga commentedon Jan 21, 2025
Could be, @picnixz, but I do not think so. As @JelleZijlstra pointed out:
while #124363, as long as I understand, is related to raw strings and escape characters, which is not the case here.
The problem here seems to be that the expression text is printed up to
!while the expression itself is correctly evaluated, such as in the following example:Notice that:
Even
=sign is omitted in!=expressions.gh-129093: Fix f-string debug text sometimes getting cut off when exp…
pythongh-129093: Fix f-string debug text sometimes getting cut off wh…
[3.12] pythongh-129093: Fix f-string debug text sometimes getting cut…
pablogsal commentedon Jan 22, 2025
Thanks everyone for the investigation and thanks @tomasr8 for the analysis. Fantastic job!
[3.12] gh-129093: Fix f-string debug text sometimes getting cut off w…
[3.13] gh-129093: Fix f-string debug text sometimes getting cut off w…
JD-Veiga commentedon Jan 22, 2025
Thanks to everybody. This was awesome.