New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
comparison chaining has wrong source positions in most contexts (python 3.11.0rc2) #95921
Comments
…sert rewriting This affects also chained comparisons inside normal assertions because of python/cpython#95921. This is also the reason for the changes in sample results. once that is fixed we could revert the changes in the sample_results
|
@brandtbucher I think this is related to #93691. Does it makes sense for me to look into it? I have (almost) no cpython core developer experience and it would take me probably far longer than someone else. |
|
Thanks for the detailed report. This issue seems to stem from the fact that we have two implementations of comparisons in the bytecode compiler: one generic version ( I’ll have a fix up either today or tomorrow. It will probably need to wait for 3.11.1, though. |
…thonGH-96968). (cherry picked from commit dfc73b5) Co-authored-by: Brandt Bucher <brandtbucher@microsoft.com>
…thonGH-96968). (cherry picked from commit dfc73b5) Co-authored-by: Brandt Bucher <brandtbucher@microsoft.com>
…thonGH-96968). (cherry picked from commit dfc73b5) Co-authored-by: Brandt Bucher <brandtbucher@microsoft.com>
|
Thanks again for the great bug report! |
|
Big thank you for the quick bugfix @brandtbucher. But the fix caused another bug. The script: def func():
assert a and b<c , "msg"
import dis
for i in dis.get_instructions(func):
if i.opname in ("COMPARE_OP","CALL"):
print(i.positions,i.opname,i.argval)output (with your fix): Positions(lineno=4, end_lineno=4, col_offset=17, end_col_offset=20) COMPARE_OP <
Positions(lineno=4, end_lineno=4, col_offset=17, end_col_offset=20) CALL 0You see that the positions of the output (the commit before your fix): Positions(lineno=4, end_lineno=4, col_offset=17, end_col_offset=20) COMPARE_OP <
Positions(lineno=4, end_lineno=4, col_offset=4, end_col_offset=28) CALL 0The positions of the This did not cause any incorrect Tracebacks (at least I don't know how to produce it), but can cause problems for tools which analyse this positions. |
|
It is maybe also important that this is not the only example. assert b<c , "msg"
assert a<b<c , "msg"
assert a+b<c , "msg"show the same problems. I looks like everything with one or more |
|
Yep, I see the issue. My patch sets the location when recursing into the expression, but doesn't restore it after. |
15r10nk commentedAug 12, 2022
•
edited
problem
comparison chaining has wrong source positions in most contexts
This bug requires two things to happen:
==,in,<=,is,...)no problem
The following examples work:
only one comparison
inside expression
reason
The problem seems to be the positions in the compiled bytecode:
script:
output (Python 3.11.0rc2+):
the generated ast looks fine (snippet):
other examples
here is a list of all the problems I found so far:
expected result
The positions should always match the ast-node range:
or, even better only the failing comparison:
The text was updated successfully, but these errors were encountered: