Linked by Thom Holwerda on Thu 27th Jul 2006 17:12 UTC, submitted by bkavanaugh
.NET (dotGNU too) Microsoft has shipped the release candidate for IronPython 1.0 on its CodePlex community source site. IronPython is a project that implements the dynamic object-oriented Python language on top of the Microsoft Common Language Infrastructure. IronPython is both well-integrated with the .Net Framework and is a true implementation of the Python language.
Order by: Score:
I certainly hope...
by ma_d on Thu 27th Jul 2006 18:25 UTC
Member since:

This doesn't do for Python what Microsoft's Java implementation did against Java.

Reply Score: 2

RE: I certainly hope...
by Shkaba on Thu 27th Jul 2006 20:16 UTC in reply to "I certainly hope..."
Shkaba Member since:

We can all hope ... but past has proven that it most likely will

Reply Score: 1

RE[2]: I certainly hope...
by thebluesgnr on Thu 27th Jul 2006 21:29 UTC in reply to "RE: I certainly hope..."
thebluesgnr Member since:

Unlike "Microsoft Java", this is free software. You can run it on top of Mono if you'd like.

Reply Score: 3

RE[3]: I certainly hope...
by ma_d on Thu 27th Jul 2006 21:32 UTC in reply to "RE[2]: I certainly hope..."
ma_d Member since:

Microsoft's Shared Source CLI, C#, And Jscript License

This license does not permit commercial distribution, and only allows commercial use under certain circumstances.

Microsoft has other licenses which it describes as "Shared Source", some of which have different restrictions.

Reply Score: 0

RE[4]: I certainly hope...
by BrianH on Thu 27th Jul 2006 22:09 UTC in reply to "RE[3]: I certainly hope..."
BrianH Member since:

Before you pull out the FSF criticism, you should know that the license they are referring to is not the license for IronPython. Here is the license for IronPython:

In summary, commercial and non-comercial use is OK, there is a warranty disclaimer and limitation of liability that you must pass on (but no cover-their-legal-bills clause), and there is a don't sue anyone over patents related to this software or you'll lose the license clause.

Basically BSD plus patent handling. Good license overall.

Reply Score: 5

RE: I certainly hope...
by jmansion on Fri 28th Jul 2006 08:11 UTC in reply to "I certainly hope..."
jmansion Member since:

Remind me what that was? At the time I was entirely in favour of the COM compatible extensions, and regarded Sun's stance critically. I still do. Having
a garbage collected 'safe' language with which to write COM components would have been a boon - and it would have enabled me to start migrating core functions from Win32-specific C to portable Java and then deploy it elsewhere, which would have accelerated my Java use. Sun's suggestion that I need to be saved from writing Windows-specific code and would be unable to determine which bits of my system could be portable and which specific is and was insulting.

Reply Score: 1

by ma_d on Thu 27th Jul 2006 18:27 UTC
Member since:

IronPython also leverages the CLI to achieve good performance, running up to 1.5 times faster than the standard C-based Python implementation on the standard Pystone benchmark.
Honestly I expected to see more of a speed gain, I guess CPython is more efficient than I'd thought it was.

Reply Score: 2

RE: Speed
by snowbender on Thu 27th Jul 2006 20:25 UTC in reply to "Speed"
snowbender Member since:

I too initially expected more of a speed gain, but only because I thought that by default, Python used a simple interpreter (an abstract syntax tree interpreter just like Ruby), but CPython, the standard Python implementation has a bytecode compiler and a bytecode interpreter, which is already faster. So, we are comparing running Python on a virtual machine with accompanying instruction set specifically designed to run Python code with a virtual machine which was more or less designed from the ground up to support several different languages. So, I think that a 1.5 speedup factor is not that bad.

I do wonder whether the JIT is activated/works and how much of a difference the JIT can make in the Pystone benchmark (I don't know the benchmark). I imagine that with dynamic languages like Python, and also Ruby, a JIT can't improve performance much in a benchmark which mainly consists of method calls and not of pure computations.

Also something to take into account is that CPython uses reference counting (with a fallback on a real garbage collector for cycles), which increases the cost of creating/removing references, while the CLR uses mark-compact garbage collection (which will most likely be cheaper overall). So, I think part of the speedup also comes from this, but that also depends on the characteristics of the benchmark.

Reply Score: 5

RE[2]: Speed
by ma_d on Thu 27th Jul 2006 21:30 UTC in reply to "RE: Speed"
ma_d Member since:

Yes, a computation benchmark would be great. I know from experience that Python does nothing to optimize complex computations, or nothing very useful, compared with languages like Java (the Sun implementation).

Reply Score: 1

RE[2]: Speed
by PlatformAgnostic on Fri 28th Jul 2006 04:16 UTC in reply to "RE: Speed"
PlatformAgnostic Member since:

I don't think .NET has an interpreter at all. All code that is executed is JITTed beforehand. The speed gain is probably from the fact that IronPython is running native code once the methods are jitted and CPython is interpreting bytecode. Dynamic method invocation used to be really slow in .NET and the code could not be thrown away when the method was no longer needed. In the CLR 2.0, there is a DynamicMethod class which can be GCed just like any other class when references to it go away.

Another reason IP is faster is likely the more efficient implementation of Python datastructures within the .NET class library. A lot more time and money probably went into optimizing everything in .NET than in CPython.

Reply Score: 1

A bit slow....
by snowflake on Thu 27th Jul 2006 18:35 UTC
Member since:

I agree, I was a bit disappointed in the speed up, only 1.5, I was expecting more. Ive translated some nontrivial C programs into C# and seen the C# apps run at about 70% of the C versions, its a rough estimate admitedly but not too bad so I was expecting python to deliver more, presumably dynamic language invokation is slow.

Reply Score: 2