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
ast.literal_eval does not properly handled complex numbers #49157
Comments
ast.literal_eval does not properly handle complex numbers: >>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
Traceback (most recent call last):
...
ValueError: malformed string
>>> ast.literal_eval("(2+1j)")
Traceback (most recent call last):
...
ValueError: malformed string Expected result: >>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
(2+1j)
>>> ast.literal_eval("(2+1j)")
(2+1j) I attached a patch that fixes this problem. |
fixed patch :) |
Looks good to me assuming you add a test. |
I'm not sure that this is desirable behaviour. There's no such thing as a In any case, I'm not sure that the patch behaves as intended. For >>> ast.literal_eval('2 + (3 + 4j)')
(5+4j) |
BTW, both those "I'm not sure"s should be taken literally: I'm not a user IOW, take my comments with a large pinch of salt. |
Here a patch with unittests to correctly handle complex numbers. This |
Nit: the "except" should only catch ValueError. |
Nice fix! Exactly which complex strings should be accepted here? >>> ast.literal_eval('-1+-3j')
(-1-3j)
>>> complex('-1+-3j')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: complex() arg is a malformed string and it produces different results from the complex >>> complex('-0.0+0.0j').real
-0.0
>>> ast.literal_eval('-0.0+0.0j').real
0.0 But since I don't really know what ast_literal It still seems odd to me to be doing just one |
literal_eval has eval() semantics and not complex() constructor For exmaple "(2 + 4j)" is perfectly fine even though the complex call I commit the fix with the ValueError except Georg suggested. |
So why accept (4+2j) but not (2j+4)? (BTW, I'm fairly sure that the complex constructor does |
Indeed, it accepts parentheses in 2.6 now, but not in 2.5 or earlier. Why not the other way round? Somewhere there has to be a limit. And if But let's try no to make this a bikeshed discussion. If you say that |
Fixed in rev68571. |
Why didn't you use assertRaises in place of that try/except for a test ? I was somewhat following this issue and just saw it being commited, but |
Sorry, yes, that makes perfect sense. (And now I see that that's what |
|
I assume from the discussion that the patch was accepted/committed and FWIW, list displays, for instance, are not literals either but are |
Fixed handling on unary minus in r85314. In so doing, it also liberalized what literal_eval() accepts (3j+4 for example). This simplified the implementation and removed an unnecessary restriction which wasn't needed for "safety". |
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: