A faster Python?, Python compiler, Dylan,...

[Ian Bicking]

On Tue, 2002-04-09 at 00:32, Chris Tavares wrote:
> 
> "Greg Ewing" <greg at cosc.canterbury.ac.nz> wrote in message
> news:mailman.1018314090.9984.python-list at python.org...
> [ ... snip ... ]
> >
> > I'm not sure that Pyrex will ever compile *all* valid Python
> > code. It probably wouldn't be very effective at speeding up
> > pure Python code anyway. The reason it deals with Python code
> > at all is so that you can write code to convert between
> > Python and C data structures -- the fact that you can
> > compile pure Python with it is sort of a side effect.
> >
> [ ... snip ... ]
> 
> It could be interesting to see how far you could get with just the subset
> you do compile, though. The Squeak people can compile their entire VM from
> Smalltalk to C, and their translator doesn't even do classes or objects! And
> they get a big, big win from it in terms of portability and ease of
> experimentation.

One of the big advantages they had of this system was that they could
run the VM inside Squeak and use Squeak's excellent debugging tools
(well, I think they were actually running it in another version of
Smalltalk when they were bootstrapping).  The language was a subset of
Smalltalk, which made this possible.  Pyrex isn't a subset, since it
introduces new keywords and static types -- the static types could
potentially be ignored, with the expectation that you might encounter
new type-related bugs when you moved to C.  This would have been an
issue for Squeak as well -- it's certainly no closer to C than Python --
but I don't know how they solved this problem.

Of course, Python has never had the insular ambitions that
Squeak/Smalltalk has, so a Pure Python World isn't as compelling.  But
that doesn't mean prototyping Pyrex code in interpreted Python wouldn't
be very nice -- especially since Pyrex runtime errors are unlikely to
have nice tracebacks (or even very readable translated C code).  Maybe
all that's required is a custom loader that filters out cdef and type
declarations.  Better yet if some of the type declarations could be
turned into asserts (though I don't know how you'd ensure that the
variable remained the correct type for the entire time -- just when a
function was first called).

  Ian