[issue15245] ast.literal_eval fails on some literals

Change by Serhiy Storchaka : -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker ___ __

[issue15245] ast.literal_eval fails on some literals

Mark Dickinson added the comment: > The question is should we make it working in older versions? That seems like an easy question: it would be a new feature in a bugfix branch, so no, we shouldn't make it work in older versions. Looks to me as though this issue can be closed. -- _

[issue15245] ast.literal_eval fails on some literals

Serhiy Storchaka added the comment: ast.literal_eval('...') works in 3.8. The question is should we make it working in older versions? -- nosy: +serhiy.storchaka ___ Python tracker _

[issue15245] ast.literal_eval fails on some literals

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue15245] ast.literal_eval fails on some literals

Changes by João Bernardo : Added file: http://bugs.python.org/file26266/ast.py_tests_doc.diff ___ Python tracker ___ ___ Python-bugs-list mail

[issue15245] ast.literal_eval fails on some literals

Éric Araujo added the comment: No, the rst documentation is maintained manually. Look for versionchanged in the doc source files or the documentation about writing documentation to see how to document the new argument (and new supported Ellipsis literal). --

[issue15245] ast.literal_eval fails on some literals

João Bernardo added the comment: Just to be sure: What's a doc update? The `.rst` files are updated automatically with the doc strings? The adding another argument should require a: "Changed in version 3.x: Accepts a second argument ..." ? -- ___ P

[issue15245] ast.literal_eval fails on some literals

Éric Araujo added the comment: Thanks for the patch. It looks good to me, but I think that adding support for Ellipsis and adding a new parameter to allow extra names are two different requests, but someone more knowledgeable than me about AST may judge differently. My rationale is that sup

[issue15245] ast.literal_eval fails on some literals

Changes by João Bernardo : Added file: http://bugs.python.org/file26264/ast.py_with_tests.diff ___ Python tracker ___ ___ Python-bugs-list mai

[issue15245] ast.literal_eval fails on some literals

Amaury Forgeot d'Arc added the comment: Ah right, that's confusing indeed... Unit tests and doc updates are needed though. -- ___ Python tracker ___ ___

[issue15245] ast.literal_eval fails on some literals

João Bernardo added the comment: Ellipsis in this context is `_ast.Ellipsis`, not the original one... There's no TypeError there as `_ast.Ellipsis` is a class. -- ___ Python tracker __

[issue15245] ast.literal_eval fails on some literals

Amaury Forgeot d'Arc added the comment: I like the 'safe_names' idea, but is this patch supposed to work? >>> isinstance(None, Ellipsis) TypeError: isinstance() arg 2 must be a type or tuple of types -- nosy: +amaury.forgeotdarc ___ Python tracker

[issue15245] ast.literal_eval fails on some literals

Changes by Éric Araujo : -- keywords: +needs review stage: -> test needed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue15245] ast.literal_eval fails on some literals

Changes by João Bernardo : -- keywords: +patch Added file: http://bugs.python.org/file26262/ast.py.diff ___ Python tracker ___ ___ Pyt

[issue15245] ast.literal_eval fails on some literals

Changes by Éric Araujo : -- nosy: +eric.araujo, georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue15245] ast.literal_eval fails on some literals

João Bernardo added the comment: Of course `nan` and `inf` are part of the syntax! The `ast.parse` function recognize them as `Name`. So that works: >>> ast.dump(ast.parse('True')) "Module(body=[Expr(value=Name(id='True', ctx=Load()))])" >>> ast.dump(ast.parse('inf')) "Module(body=[Expr(val

[issue15245] ast.literal_eval fails on some literals

Mark Dickinson added the comment: > I don't think literal_eval should handle anything which is not syntax. +1 -1 on supporting 'inf' and 'nan' -0 on supporting 'Ellipsis' or '...'; seems harmless, but I don't really see the point. -- ___ Python tr

[issue15245] ast.literal_eval fails on some literals

Benjamin Peterson added the comment: I don't think literal_eval should handle anything which is not syntax. -- ___ Python tracker ___ ___

[issue15245] ast.literal_eval fails on some literals

João Bernardo added the comment: That's what I said by `nan` and `inf` are not literals, but their representations look like they should be. One solution could be to add another argument to allow some extra names. Maybe a mapping, as `eval`. -- __

[issue15245] ast.literal_eval fails on some literals

Daniel Urban added the comment: eval(repr(float('nan'))) doesn't work either, so I'm not sure ast.literal_eval should. The same with float('inf'). -- nosy: +daniel.urban ___ Python tracker ___

[issue15245] ast.literal_eval fails on some literals

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue15245] ast.literal_eval fails on some literals

Changes by Antoine Pitrou : -- nosy: +benjamin.peterson title: ast.literal_eval on some literals -> ast.literal_eval fails on some literals versions: +Python 3.4 -Python 3.3 ___ Python tracker