Terry J. Reedy <tjre...@udel.edu> added the comment: >From a top level view, the patch adds PyAST_Validate (with helpers) to ast.c >and one call to PyAST_Validate in bltinmodule.c in builtin_compile(). The >added tests do every silly thing you can think of.
Does PyAST_Validate get invoked for all calls to compile() or just those with an ast as input. To put it another way, does it validate *all* asts, including those generated by the code parser, or just user-constructed asts. If just the latter now, it seems that turning it on for parser asts at least temporarily could test that it does not invalidate valid code and could be used to test an ast-level optimizer. Two obvious questions: 1) does this address a real problem that has happened in the field or something that just *might* happen; 2) what is the time penalty (compared to the time of compilation). I guess these amount to "Is the maintenance burden on developers and speed burden on users worth the benefit?". In theory, I am in favor of anything that prevents segfaults. Would that ctypes use could be similarly validated (yes, this is a joke;-). A last question, whose answer might depend on those above: given that the new function is not exposed to users, why not validate as part of compilation, to avoid walking the tree twice? ---------- nosy: +terry.reedy stage: -> patch review type: -> feature request _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12575> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com