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

Reply via email to