Python compilers?

[skaller]

Stephan Houben wrote:
> 
> On 27 Sep 1999 03:07:27 -0500, Nolan Darilek <nolan at ethereal.dhis.org> wrote:
> >I've been programming with C++ for nearly a year, and after seeing how
> >other languages are structured, and their benefits, I'm becoming
> >disenchanted with it.

My advice is: don't give it up so easily. C++ is not known for
nice syntax, as Python is. [IMHO Python has one of the nicest syntaxes
of any language I've seen]

OTOH, you can do a lot of work in C++, albiet clumbsily, and the results
are likely to be very fast, relatively portable, and, importantly,
under your control. Modern C++ compilers are quite good, compared
to even those available 12 months ago: they implement most of the
ISO C++ Standard correctly.

> >So, I've been searching for another language. One item which I would
> >like to have, though, is the ability to compile to native code. 

Try ocaml 2.02 [http://caml.inria.fr] It is an ML dialect with
functional,
procedural, and object oriented components, and it generates both
byte code and native code. Performance varies from 'OK' to 'faster than
C'.
Runs on Unix andd Windows. A much better alternative than C++ or Python
for a game (because it has a built in garbage collector).

> >So, are there any native Python compilers? Someone on IRC mentioned a project
> >called Viper, and my searches seem to indicate that it is under
> >development, but is there any information on the web about its status?
> 
> I don't think it's ready for prime time...
> and that's probably an understatement.

	That's correct. The interpreter Viperi is now running well enough
to execute the pystone benchmark .. 10 times slower than CPython 1.5.2.
Some of the functionality, however, is already faster than Python.
For example, long integer seem faster. On the other hand, list
concatenation is currently 100 times slower (I wish I knew why,
the code is compiled down to machine code, there is no interpeter
overhead
involved).

	So, one could say that Viperi is fairly close to being
usable now, if you'll accept lower performance -- and an almost
complete lack of any libraries. :-) However, there'd be no
point, unless you wanted to experiment with the new type system,
or use some of the other new features like rational arithmatic,
full implementation of extended slicing syntax, support for
ISO-10646 (unicode) via UTF-8 .... 

	OTOH, the compiler is barely commenced.
However, this is not so difficult as one might think. The biggest
problem
providing a python compatible compiler is library integeration.
Viper's solution is simple. It wont. This is quite deliberate.
The idea is that all the libraries should be written IN PYTHON,
there is little need for C libraries once you have a python compiler.

	Of course, support for basic things, like socket I/O, must still
be provided by the system, and pragmatically, a way to interface
existing C libraries [NOT python C modules] is necessary. This already
exists [it is provided by the host language plus a mechanism to
extend the Viper system in the host language]

	So my guess is: the compiler/interpreter will be useful
quite quickly, for developing NEW applications, or for doing
serious mathematical and text programming, it will take much
longer to provide interfaces to existing codes, and even longer
to make it all work compatibly with existing python codes.

	However, a special case of the latter is my primary
goal -- to compile my python application 'interscript'.
	 
-- 
John Skaller, mailto:skaller at maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller