Linked by Eugenia Loli on Sun 28th Mar 2004 19:50 UTC, submitted by Mysterious & SwaroopCH
General Development 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.
Order by: Score:
Speed Improvements...
by Anonymous on Sun 28th Mar 2004 20:22 UTC

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!

Why is IronPython faster than CPython?
by Rayiner Hashem on Sun 28th Mar 2004 20:28 UTC

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.

not bad....
by Debman on Sun 28th Mar 2004 20:29 UTC

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 :-)

Parrot
by johnMG on Sun 28th Mar 2004 20:54 UTC

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? ;)

JPython vs. IronPython
by Roy Batty on Sun 28th Mar 2004 20:54 UTC

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.

@johnMG
by Roy Batty on Sun 28th Mar 2004 20:56 UTC

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?

dead link in article
by johnMG on Sun 28th Mar 2004 20:57 UTC

Well, the link provided ( http://ironpython.com ) only leads to an empty page ( http://want-of-a-nail.com/ ) for me right now.

re future Python bytecode
by johnMG on Sun 28th Mar 2004 21:01 UTC

> 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.)

...
by Dolemite on Sun 28th Mar 2004 21:03 UTC

page is empty and probably it won't be free...

code && inheritance
by fuser on Sun 28th Mar 2004 21:21 UTC

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 ;)

@JohnMG
by Roy Batty on Sun 28th Mar 2004 21:41 UTC

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.

@Roy
by johnMG on Sun 28th Mar 2004 22:01 UTC

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.

And the great question is......
by Mike on Sun 28th Mar 2004 22:18 UTC

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.

@Mike
by Rayiner Hashem on Sun 28th Mar 2004 22:45 UTC

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.

if it is compiled to bytecode...the runtime is not used
by Debman on Sun 28th Mar 2004 22:53 UTC

so how can it throw up an exception?

@Debman
by Rayiner Hashem on Sun 28th Mar 2004 23:10 UTC

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.

Generics
by Anonymous on Mon 29th Mar 2004 00:44 UTC

I think generics can solve some of the problems with dynamic languages like python.

@Anonymous
by Rayiner Hashem on Mon 29th Mar 2004 00:50 UTC

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.

generics in python?
by Debman on Mon 29th Mar 2004 05:02 UTC

why? it is a dynamically typed language as you said...there is no need for generics.

@Debman
by Rayiner Hashem on Mon 29th Mar 2004 05:26 UTC

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).

Parrot
by Steven Haryanto on Mon 29th Mar 2004 05:36 UTC

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@[172.24....]

Can't wait.

@Steven Haryanto
by rod on Mon 29th Mar 2004 13:49 UTC

The link is wrong, can you post it again?

@rod
by Steven Haryanto on Mon 29th Mar 2004 22:42 UTC

It's OSNews comment parser. Copy the link and add the "]" that OSNews left out.