[issue4907] ast.literal_eval does not properly handled complex numbers

Raymond Hettinger added the comment: 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". -- nosy: +rhettin

[issue4907] ast.literal_eval does not properly handled complex numbers

Terry J. Reedy added the comment: I assume from the discussion that the patch was accepted/committed and changed the resolution and stage field to match. FWIW, list displays, for instance, are not literals either but are successfully evaluated, so doing same for complex 'displays' seems sensibl

[issue4907] ast.literal_eval does not properly handled complex numbers

Armin Ronacher added the comment: > Why didn't you use assertRaises in place of that try/except for a test ? Could be changed. > I was somewhat following this issue and just saw it being commited, > but the change was being discussed. Aren't you supposed to commit > these kind of changes only a

[issue4907] ast.literal_eval does not properly handled complex numbers

Mark Dickinson added the comment: > If you say that > literal_eval can safely evaluate the repr() of builtins Sorry, yes, that makes perfect sense. (And now I see that that's what distinguishes 4+2j from 2j+4---finally the light dawns.) Apologies for being obtuse.

[issue4907] ast.literal_eval does not properly handled complex numbers

Guilherme Polo added the comment: 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 the change was being discussed. Aren't you supposed to commit these kind of changes only after entering in agreement

[issue4907] ast.literal_eval does not properly handled complex numbers

Armin Ronacher added the comment: Fixed in rev68571. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue4907] ast.literal_eval does not properly handled complex numbers

Armin Ronacher added the comment: 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 you write down complex numbers you usually have the imaginary part after the real part. But let's try no to make this

[issue4907] ast.literal_eval does not properly handled complex numbers

Mark Dickinson added the comment: So why accept (4+2j) but not (2j+4)? (BTW, I'm fairly sure that the complex constructor does accept parentheses; you're right about the whitespace, though.) ___ Python tracker ___

[issue4907] ast.literal_eval does not properly handled complex numbers

Armin Ronacher added the comment: literal_eval has eval() semantics and not complex() constructor semantics. It accepts what eval() accepts just without arithmetic and unsafe features. For exmaple "(2 + 4j)" is perfectly fine even though the complex call only supports "2+4j" (no parentheses an

[issue4907] ast.literal_eval does not properly handled complex numbers

Mark Dickinson added the comment: Nice fix! Exactly which complex strings should be accepted here? The patched version of literal-eval still accepts some things that would be rejected as inputs to complex(): >>> ast.literal_eval('-1+-3j') (-1-3j) >>> complex('-1+-3j') Traceback (most recent ca

[issue4907] ast.literal_eval does not properly handled complex numbers

Georg Brandl added the comment: Nit: the "except" should only catch ValueError. -- nosy: +georg.brandl ___ Python tracker ___ ___ Pyth

[issue4907] ast.literal_eval does not properly handled complex numbers

Armin Ronacher added the comment: Here a patch with unittests to correctly handle complex numbers. This does not allow the user of arbitrary add/sub expressions on complex numbers. Added file: http://bugs.python.org/file12707/literal-eval.patch ___ Python t

[issue4907] ast.literal_eval does not properly handled complex numbers

Mark Dickinson added the comment: BTW, both those "I'm not sure"s should be taken literally: I'm not a user of the ast module, I don't know who the typical users are, and I don't know what the typical uses for the literal_eval function are. The patch just struck me as odd, so I thought I'd

[issue4907] ast.literal_eval does not properly handled complex numbers

Mark Dickinson added the comment: I'm not sure that this is desirable behaviour. There's no such thing as a complex literal---only imaginary literals. Why allow evaluation of 2+1j but not of 2 + 1, or 2*1j. In any case, I'm not sure that the patch behaves as intended. For example, >>> ast

[issue4907] ast.literal_eval does not properly handled complex numbers

Benjamin Peterson added the comment: Looks good to me assuming you add a test. -- keywords: -needs review nosy: +benjamin.peterson ___ Python tracker ___ ___

[issue4907] ast.literal_eval does not properly handled complex numbers

Armin Ronacher added the comment: fixed patch :) Added file: http://bugs.python.org/file12675/literal-eval.patch ___ Python tracker ___ ___ Py

[issue4907] ast.literal_eval does not properly handled complex numbers

New submission from Armin Ronacher : 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): ...