Super-Fast Python Implementation for .NET and Mono

Lansdowne writes "Jim Hugunin, the creator of Jython, has released an incredibly fast implementation of Python for Microsoft .NET and Mono called IronPython. Here's his PyCON 2004 presentation, including some benchmarks. He concludes: 'Python is an extremely dynamic language and this offers compelling evidence that other dynamic languages should be able to run well on this platform.'"

Comments

cool stuff

[hattmoward]

I'm glad to see more alternative languages for the .NET/Mono platform... If we're gonna get stuck with it, we may as well make the best of it! :) Seeing Python run nice and fast, being a dynamic language and on a VM, is great stuff too.

not released

[the quick brown fox]

I usually take "released" to mean there is an implementation that is publicly available. Unless I am somehow just missing it, it doesn't seem to have been released yet...

Re:Compiled Python

[FrenZon]

I haven't worked with Python yet though I plan to take a look at it soon. I know it is a scripting language but is there a way to compile it into native executable form?

"You don't need the ability to compile Python to C code if all you want is a stand-alone program that users can download and run without having to install the Python distribution first. There are a number of tools that determine the set of modules required by a program and bind these modules together with a Python binary to produce a single executable..." Read More

Re:Next Question

[Chester K]

Is there anything the MONO team can do to improve support for dynamic languages?

Mono, today, actually would support dynamic languages better than Microsoft's framework, since they implement the DynamicMethod class, which Microsoft fully documents in their Longhorn SDK documentation, but won't actually be released until .NET 2.0 comes out.

The DynamicMethod class allows you to load a method into memory for JITting and execution, and preserves the ability for you to unload that code from memory, which you can't do with full-fledged Assemblies, even those generated via Reflection.Emit -- in .NET, once an Assembly is loaded into memory, it stays there until the AppDomain quits.

What changed?

[ameoba]

I remember some previous attempt to do Python under .NET that was painfully slow & eventually written off as a failure and blamed on .NET's inability to handle the level of dynamism required to implement Python. What's changed since then?

Are we looking at some sort of fundamental breakthrough in working with the CLR here or was the problem simply tackled by a more experienced/insightful developer?