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 
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.literal_eval('2 + (3 + 4j)')
(5+4j)

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 comment.

IOW, take my comments with a large pinch of salt.

Here a patch with unittests to correctly handle complex numbers.  This
does not allow the user of arbitrary add/sub expressions on complex numbers.

Nit: the "except" should only catch ValueError.

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 call last):
  File "<stdin>", line 1, in <module>
ValueError: complex() arg is a malformed string

and it produces different results from the complex
constructor in some other cases:

>>> 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
is used for, I don't know whether this matters.

It still seems odd to me to be doing just one
special case of expression evaluation in
ast_literal, but maybe that's just me.

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 and whitespace).

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
accept parentheses;  you're right about the whitespace, though.)

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 a bikeshed discussion.  If you say that
literal_eval can safely evaluate the repr() of builtins (with the
notable exception of reprs that eval can't evaluate either [like nan,
inf etc.]) and probably a bit more it should be fine :)

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
the change was being discussed. Aren't you supposed to commit these kind
of changes only after entering in agreement with others ?

> 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.

> 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 after entering in agreement with others ?
The "needs review" keyowrd was removed, I was under the impression I can
commit now :)

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
sensible to me too, and in line with the purpose of the method.

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".