Python compilers?

[Heather Coppersmith]

On Fri, 21 May 2004 03:03:51 GMT,
Carl Banks <imbosol at aerojockey.invalid> wrote:

> Paul Rubin wrote:
>> 
>> 
>> Carl Banks <imbosol at aerojockey.invalid> writes:
>>> > The example above kills any attempt to turn a.bar() into a static
>>> > procedure call.
>>> 
>>> Of course it does--but it's one method.  A compiler, if it's good,
>>> would only make the optization on methods named "bar", and it could
>>> probably pare the number of possible classes it could happen to down
>>> to only a few.
>> 
>> How could it possibly know?  The reassignment of a.bar could happen
>> anytime, anywhere in the code.  Maybe even in an eval.

> And if it happens anytime, anywhere in the code, the compiler will see
> it and create more general code.  Or is that impossible?

The compiler might not see it.  Any function/method/module called while
a is in scope might change a.bar.  It doesn't even take a perverted
introspection tool:

    module foo:

    import bar
    class C:
        pass
    a = C( )
    a.bar = 'bar'
    bar.bar( a )
    a.bar = a.bar + 'bar' # which 'add' instruction should this compile to?

    module bar:

    def bar( x ):
        x.bar = 3

> As for eval, well it would be silly to even allow eval in a compiled
> program; kind of defeats the purpose of compling.  You might let it
> run in its own namespace so it can only affect certain objects.

I reiterate my comments regarding type declarations, add new comments
regarding backwards compatibility, and note that Lisp allows eval in
compiled code.

Regards,
Heather

-- 
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli