I think this is a bug in literal_eval:

>>> 3+6j
(3+6j)
>>> 6j+3
(3+6j)
>>> ast.literal_eval('3+6j')
(3+6j)
>>> ast.literal_eval('6j+3')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\User\src\cpython\lib\ast.py", line 105, in literal_eval
    return _convert(node_or_string)
  File "C:\Users\User\src\cpython\lib\ast.py", line 104, in _convert
    return _convert_signed_num(node)
  File "C:\Users\User\src\cpython\lib\ast.py", line 78, in _convert_signed_num
    return _convert_num(node)
  File "C:\Users\User\src\cpython\lib\ast.py", line 69, in _convert_num
    _raise_malformed_node(node)
  File "C:\Users\User\src\cpython\lib\ast.py", line 66, in _raise_malformed_node
    raise ValueError(f'malformed node or string: {node!r}')
ValueError: malformed node or string: <ast.BinOp object at 0x023D0910>


literal_eval accepts complex rhs, but not lhs: 
https://github.com/python/cpython/blame/master/Lib/ast.py#L99
if isinstance(left, (int, float)) and isinstance(right, complex):

This was introduced here, I'm not sure why:
https://github.com/python/cpython/commit/d8ac4d1d5ac256ebf3d8d38c226049abec82a2a0


In Nick's aborted patch, he removed that check.