[issue39159] Ideas for making ast.literal_eval() usable

Raymond Hettinger added the comment: > Can you explain it a bit more detailed, > how does this standalone expression compiler should work? Aim for something like JSON parser but for the supported Python constant expressions and with the existing tokenize module to feed a hand-rolled on-recu

[issue39159] Ideas for making ast.literal_eval() usable

Raymond Hettinger added the comment: New changeset fbc7723778be01b8f3bb72d2dcac15ab9fbb9923 by Batuhan Taskaya in branch 'master': bpo-39159: Declare error that might be raised from literal_eval (GH-19899) https://github.com/python/cpython/commit/fbc7723778be01b8f3bb72d2dcac15ab9fbb9923 ---

[issue39159] Ideas for making ast.literal_eval() usable

Change by Emmanuel Arias : -- nosy: +eamanu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue39159] Ideas for making ast.literal_eval() usable

Serhiy Storchaka added the comment: It can also crash. ast.literal_eval('+0'*10**6) The cause is that all AST handling C code (in particularly converting the AST from C to Python) is recursive, and therefore can overflow the C stack. Some recursive code has arbitrary limits which cause

[issue39159] Ideas for making ast.literal_eval() usable

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19210 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19899 ___ Python tracker ___

[issue39159] Ideas for making ast.literal_eval() usable

Batuhan Taskaya added the comment: > 1) We should document possible exceptions that need to be caught. So far, > I've found TypeError, MemoryError, SyntaxError, ValueError. Also, an addition to these errors is RecursionError >>> t = ast.Tuple(elts=[], ctx=ast.Load()) >>> t.elts.append(t) >>>

[issue39159] Ideas for making ast.literal_eval() usable

Batuhan Taskaya added the comment: > 1) We should document possible exceptions that need to be caught. So far, > I've found TypeError, MemoryError, SyntaxError, ValueError. Maybe we should wrap all of these into something like LiteralEvalError to easily catch all of them, LiteralEvalError c

[issue39159] Ideas for making ast.literal_eval() usable

New submission from Raymond Hettinger : A primary goal for ast.literal_eval() is to "Safely evaluate an expression node or a string". In the context of a real application, we need to do several things to make it possible to fulfill its design goal: 1) We should document possible exceptions t