[summerofcode] High-level python optimizer.

[Armin Rigo]

Hi Vova,

On Sun, Jun 12, 2005 at 03:23:58PM +0400, Vova wrote:
> Ok, you are right, exec is a bad thing for my algorithm.

Once you agree to that, the next step is to realize that you don't
actually need an "exec" statement for equally bad things to happen.
Strange code can perform arbitrary computations whose side effects
include changes to global invariants in ways that cannot easily be
tracked.  You will likely find yourself defining a number of "forbidden"
things that can potentially break the whole idea.  Here is a very short
list:

 - all exec's, eval(), execfile(), new.code(), marshal.load()
 - sys.path manipulations that control where "import" statements will
     find modules at run-time
 - __import__() where the module name cannot be predicted
 - setattr(), delattr() where the attribute name cannot be predicted
 - calling any built-in function or type that you don't know about
     (!!! this one is a killer!  quite a lot of efforts and maintenance)
 - passing around or storing some types of objects in containers where
     they won't be individually trackable any more, if they are then used
     in a way that might possibly mutate them and break invariants
     (functions, classes, types, modules, ...)

The list could be much longer.  The point is that you need, in Mark's
terms, a closed world assumption and a subset of Python in order to do
any meaningful static upper-bound type/value inference.  We even have
Brett's Thesis now, which shows exactly how far you can go if you don't
assume either of this.

If you make these assumptions, though, then your project becomes
realistic, but similar to existing projects.


A bientot,

Armin.