[issue26297] Move constant folding to AST level

Serhiy Storchaka added the comment: Issue1346238 has a patch. -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> A constant folding optimization pass for the AST ___ Python tracker

[issue26297] Move constant folding to AST level

STINNER Victor added the comment: > we need to move some optimizations from bytecode level to AST level You may be aware that there is a long list of similar (old) issues proposing something similar: https://www.python.org/dev/peps/pep-0511/#usage-1-ast-optimizer My PEP 511 tries to propose a

[issue26297] Move constant folding to AST level

STINNER Victor added the comment: Yury Selivanov added the comment: > In fact I'm -1 on using any kind of flag to trigger optimizations on or off. > Those flags will only drive confusion. If the optimizations are any good, > people will simply start using the flag all the time. Yeah, Guido c

[issue26297] Move constant folding to AST level

Yury Selivanov added the comment: > ast.Constant is *not* emited by the compiler to not break backward compatibility. I *know* that there is no stable API on AST, but I noticed some issues when working on my AST project. For example, pip doesn't work because an internal library uses AST and the c

[issue26297] Move constant folding to AST level

STINNER Victor added the comment: *If* the PEP 511 is accepted, it will be super easy to start with an implementation in pure Python. But I think that we should benchmark the overhead of the Python API of PEP 511, because we need to convert all AST internal objects to Python objects, run the AST

[issue26297] Move constant folding to AST level

New submission from Serhiy Storchaka: For using more efficient bytecode (either specialized 8-bit opcodes or 16-bit opcodes) we need to move some optimizations from bytecode level to AST level, since LOAD_CONST variants could have variable size. Now with the Constant node this should be easy.