Python compilers?

[Carl Banks]

Paul Rubin wrote:
> 
> 
> imbosol at aerojockey.com (Carl Banks) writes:
>> > >>> a.bar = lambda x: x*x*x
>> > >>> a.bar(3)
>> >  27
>> 
>> Well, come on, of course there's going to be some things here and
>> there you can do in one and not the other.  In wat is Python dynamic
>> that Lisp isn't to such an extent that it would cripple any attempts
>> to compile it?
> 
> 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.

I mean you could have a Turing nightmare on your hands, with all kinds
of crazy setattrs and execs and stuff, in both Python and Lisp, and
then there's not much a compiler could do but emit totally general
code.  I assume Lisp compilers do this sometimes.


> There's more like it, e.g. the existence of the
> locals() dictionary and the ability to modify it.

New feature?  I didn't think modifying the dict returned by locals
affected the variables.


>  However, it should
> be possible to define a reasonable subset of Python that can compile
> into good code.  The stuff that makes compilation difficult makes the
> code unmaintainable too.  

True, but even if you didn't do that, I think a compiler could do a
decent job with reasonable code.


> I do think that Python's designers should wait til PyPy with
> native-code backends has been deployed for a while before defining too
> much of Python 3.0, so we can first gain some experience with compiled
> Python.  Python should evolve towards being compiled most of the time.

Agreed


-- 
CARL BANKS                      http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work." 
          -- Parody of Mr. T from a Robert Smigel Cartoon