IronPython is a new implementation of the Python language targeting the Common Language Runtime (CLR). It compiles python programs into bytecode (IL) that will run on either Microsoft’s .NET or the Open Source Mono platform. Elsewhere, “A Byte of Python” is a free book (or free tutorial) on Python. It is meant to be a guide to anyone learning Python.
IronPython for Mono & .NET; Free Python Book
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The speed improvements shown in this article look great! I truly enjoy programming in Python, and despite some beliefs, it isn’t that slow even for applications, as long as a modern machine is used. However, a bit of extra speed from byte-compiled code cannot be a bad thing.
One thing though – the benchmarks in the article are a little confusing as the y-axis isn’t noted on the graphs. At first glance, I though that IronPython was waw slower than 2.1!
Because CPython is slow
Unlike other dynamic languages, the Python implementation doesn’t do all the extreme optimizations that implementations for other dynamic languages do. Thus, it is no surprise that when ported to .NET (and getting the benefit of JIT compilation vs pure bytecode interpretation) that IronPython comes out faster. These results would not necessarily generalize to other dynamic languages, that have highly-evolved optimizations that aren’t necessarily so easily-implemented in .NET.
this is cool because that means I cannot write a python program for windows and it will be just as fast as a managed C++ program 🙂
Wait.
|
| [IronPython] It compiles python programs into bytecode (IL)
| that will run on either Microsoft’s .NET or the Open Source
| Mono platform.
|
I thought the future of Python was to compile down to Parrot bytecode. What gives?
Also, wasn’t Iron Python one of those cool Kung-Fu dudes in those Saturday-morning movies? Didn’t he fight the drunken master?
Since JPython has been around for a while I would be interested in seeing a comparison of the challenges faced in writing compilers targetting MSIL vs. Java bytecode and any other associated issues.
this is cool because that means I cannot write a python program for windows and it will be just as fast as a managed C++ program 🙂
How do you figure? Just because its MSIL doesn’t mean the runtime is going to be able to JIT that bytecode as efficiently as something produced from a highly optimized Microsoft compiler.
I thought the future of Python was to compile down to Parrot bytecode. What gives?
and what would stop Python from eventually compiling down to Parrot bytecode?
Well, the link provided ( http://ironpython.com ) only leads to an empty page ( http://want-of-a-nail.com/ ) for me right now.
> I thought the future of Python was to compile down to
> Parrot bytecode. What gives?
>
and what would stop Python from eventually compiling down to Parrot bytecode?
Nothing of course. I just figured the community would be better off focusing efforts on a Parrot runtime than a “CLR”. (Well, that is, if I understand correctly what Parrot is.)
page is empty and probably it won’t be free…
I read the stuff from pycon IronPython presentation, but I cannot understand if it does MultipleInheritance atm.
I wonder if the interpreter will be so fast when it is completed and debugged.
Obviously if it already is that would be cool
If you read the article the guy did this out of a research interest to prove that the CLR was bad for dynamic languages. Having figured out it wasn’t, he went ahead and wrote a fullblown compiler.
If you read the article the guy did this out of a research interest to prove that the CLR was bad for dynamic languages. Having figured out it wasn’t, he went ahead and wrote a fullblown compiler.
Considering Jim’s the guy who created Jython, I certainly don’t doubt his abilities.
Beyond the syntax of Python, will any of the libraries and built-in functions really work well on .NET? I also don’t see how it will be possible for them to really use real .NET as Python has no support for interfaces and real abstract classes from what I’ve read. It would be one thing to just treat say… XmlNodeList.GetEnumerator()’s return as a Python class, but how does Python for .NET do this: class MyObject(BaseClass, IEnumerator, IComparable): ?
I think it’s really cool that Jim’s working on a means of using Python on .NET, but I am one of those people who thinks that the Python language as a whole would be better suited with a move to Parrot. It would be a real bitch for both Sun and Microsoft if Parrot not only had PERL6 and Python support, but supported a variant of VisualBasic.NET and Java all of which would be interoperable once compiled to Parrot bytecode.
Interface classes are unnecessary in Python, since all method calls are completely dynamic. In Python, if you want to support an interface, you just have to define the functions appropriate to that interface. If some code tries to call a function on an object that does not support it, the runtime will throw an exception.
so how can it throw up an exception?
Python already compiles to bytecode. CLI bytecode is just a different bytecode
So the runtime is still there. It has to be, since I doubt IronPython can use the normal CLI services for many things. For example, how would it handle method calls without the runtime? The CLI’s method calls are virtual-table based, while Python looks up the method name in a hash table. So when that bit of runtime code fails to find a method in the hash table, it’ll throw an exception.
I think generics can solve some of the problems with dynamic languages like python.
Very doubtful. Generics are just a way to get, well, genericity within a statically-typed language. Generics work when you know the type of a given variable whenever you call a method on it. In a dynamically-typed language like Python, where that is not the case, generics don’t make much sense.
why? it is a dynamically typed language as you said…there is no need for generics.
Why what? If you were responding to my post, my point was that Python doesn’t need generics (everything is generic) and generics can’t really be used to implement it (since type information is only available at runtime).
Too bad Python for Parrot is not as ready yet. It would be an exciting battle for speed 🙂
Anyway, there *will* be a rather exciting battle in July.
http://groups.google.com/groups?selm=a06010200bc18c1883507@%5B172.24….]
Can’t wait.
The link is wrong, can you post it again?
It’s OSNews comment parser. Copy the link and add the “]” that OSNews left out.