Python compilers?
Carl Banks
imbosol at aerojockey.invalid
Thu May 20 02:21:51 EDT 2004
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
More information about the Python-list
mailing list