[issue35777] mismatched eval() and ast.literal_eval() behavior with unicode_literals

jez added the comment: I take the point about breaking backward compatibility. The problem, then, is in the `ast` documentation, and may not be confined to Python 2.7 The `literal_eval` doc states no more than that the function

[issue35777] mismatched eval() and ast.literal_eval() behavior with unicode_literals

Steven D'Aprano added the comment: Python 2.7 has long passed feature freeze, and this would be new behaviour appearing in a bug-fix release, which we don't normally do. I'm going to close this as Rejected, but if you think you can make a good case for why this enhancement is sufficiently

[issue35777] mismatched eval() and ast.literal_eval() behavior with unicode_literals

New submission from Jez Hill : Following `from __future__ import unicode_literals` the expression `eval(" 'foo' ")` will return a `unicode` instance. However, using the same input, `ast.literal_eval(" 'foo' ")` will return a `str` instance. The caller's preference, that those plain