python compiled to native in less than a year?

Alex Martelli aleaxit at yahoo.com
Thu Jan 18 03:44:16 EST 2001


"Tim Roberts" <timr at probo.com> wrote in message
news:0luc6toovfccbqspkvc0dkqkuc5dck7u51 at 4ax.com...
> "scotth" <slhath at flash.net> wrote:
> >
> >Since Python will be one of the .NET languages, it will get compiled like
> >all the other .NET languages.  Whatever the problems, ActiveState/MS
> >have/are going to over come it if my info is correct.
>
> Where did you get your information?  Do you have a URL?  The other
repliers
> are delighting in nitpicking and Microsoft bashing, but no one seems to
> have questioned the basic premise.
>
> If I understand the .NET concept correctly, any COMPILED language will be
> compiled to IL.  However, I don't think there is anything to prevent a
> language from being interpreted.  That is, Python might survive in the
.NET
> framework as source text.

There's nothing stopping some piece of .NET code from "interpreting"
any piece of text whatsoever, but that wouldn't let that piece of text
be a "first-class citizen" in the .NET framework -- it could not be
used to implement classes other components inherit from, etc.  Compiling
the whatever-text-it-is down to IL is the 'royal road' of .NET integration,
and the one ActiveState is taking with their Python.NET, whose beta you
can download from their site.  Of course, that IL can perfectly well be
replete with calls to a 'runtime for my special funky language' assembly
of components -- that's a component-internal implementation decision
with .NET does not interfere with -- but what happens at a component's
interface *is* constrained by .NET interoperability rules.

The 'basic premise' that 'compiled down to IL' necessarily means anything
much from the point of view of performance IS worth questioning.  A piece
of IL that's little more than a sequence of calls to a runtime assembly
(an indirect-threaded interpreter...) will probably have performance not
substantially different from other styles of bytecode-for-interpretation,
after all.  It seems to me that Python .NET isn't really taking this easy
way out (just as Jython doesn't), but aiming at a compromise between
feasibility AND some potential performance improvement; but I have not
looked deep enough into it to be certain.


Alex






More information about the Python-list mailing list