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
Show expected input for right shift operator usage in custom "print" error message #74906
Comments
While working on issue: http://bugs.python.org/issue30597 to enhance the custom error message by showing expected output in Python3 syntax when someone uses Python2 syntax, a PR was raised: #2009, where we just handled the case for print with soft-space and excessive white-space. In the implementation discussion, an issue was raised to handle the case with right shift operator by Nick as in here: Nick suggested here about the possible patch: #2009 (comment) |
The specific error in question here is the one where Python 3 reads the old Python 2 stream redirection syntax as a combination of the right shift operator and tuple creation:
Searching for that error message indicates that people are hitting it reasonably frequently, so we may be able to save them a trip to Google by adding a custom 'Did you mean "print(<output>, file={:100!r})'.format(rhs)"? message when the right-shift operand dispatch is about to report the default "no implementation" type error, and the LHS is the print builtin. |
The test added in the PR passes on linux (Travis) and Mac (op's machine), fails on Windows (Appveyor). The patch itself modifies abstract.c. Could some Windows expert take a look? test_string_with_stream_redirection (test.test_print.TestPy2MigrationHint) ... FAIL Traceback (most recent call last):
File "C:\projects\cpython\lib\test\test_print.py", line 165, in test_string_with_stream_redirection
'file=<output_stream>)', str(context.exception))
AssertionError: 'Did you mean "print(, file=<output_stream>)' not found in "unsupported operand type(s) for >>: 'builtin_function_or_method' and '_io.StringIO'" |
The "op_slot == 96" looks suspicious - how is this value actually supposed to be calculated? |
Checking how we do it elsewhere, That's a compiler-dependent struct field offset calculation, so a discrepancy there could easily be the cause of a Windows-only failure. |
Checking the merged implementation locally, I belatedly noticed that we forgot the trailing question mark on the question:
So putting this back to "needs patch" (no NEWS entry needed, just the missing question marks in the patch and the tests). |
Ah, sorry for that. I'll just fix that right away in a few mins :) |
Note that I filed a separate issue to ask Ned about potentially backporting this to 3.6: https://bugs.python.org/issue31232 |
And done - thanks folks! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: