Python Popularity: Questions and Comments

Ulf Magnusson ulf.magnusson at ubm-computing.com
Sun Dec 30 03:39:55 EST 2001


"Courageous" wrote

> >and to defeat the speed problem: an OPTIMIZING NATIVE CODE COMPILER
>
> You're not the first person to think of this. One of the problems
> is that designing an optimizing native code compiler for a fully
> dynamic language like Python is quite a difficult task.

Yes I would be, personally I like to think of Python as the Inverse of C.
C is:
Easy to learn
Genrates fast code
and you have to write many lines of code to accomplish something.

Python is:
Hard to learn (well relativly to C)
Generates piss pore performance code (I am sorry to say)
A few lines of code does almost anything you want.

I have been a dedicated C programmer for as long as I can remember,
and a while back I realised that I had to adopt a *second* language
a second default language that is.
uhm, you know what I mean, we (community folks) learn a lot of languages
to find one or two to stick with and to do our projects in.

For me it is C and Python I am glad to say!

Where was I, oh yes, we were discussing how difficult a task it would be to
implement a compiler,
Well I guess this will follow the C Inverse theory as well
C in relativly easy and....

>
> >1. Since the language is currently evolving very rapidly it is probably
> >    a bad time to start such a project,
>
> Not really. The basic parts of Python which the compiler needs to
> support properly have been present for years. It has to do with
> first class language access to the dictionary which exists in every
> namespace, and how this first class access intertangles semantically
> with Python itself. Or at least that is one major element of the
> picture. IIRC, the generation of execution frames plays another role,
> and these likewise offer first class accessibility in Python. Again,
> they are intertwined.

Good point.

/U. Magnusson





More information about the Python-list mailing list