[summerofcode] High-level python optimizer.

Vova physics at list.ru
Sun Jun 12 14:16:14 CEST 2005


Hello !

On Sunday 12 June 2005 15:53, you wrote:
> 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, ...)
All of this is either used quite rarely or used in predictable way (i.e. 
programer can manually supply analyser with information using some kind of 
code annotations). The only question is does given speed-up costs annotation 
effort. I believe that it do.
And again: how many programs are actually executing unknown code ?

> 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.


More information about the summerofcode mailing list