Slashdot Mirror
IronPython 1.0 is Born
dougblank writes "IronPython version 1.0 was just released after 3 years of development. Jim Hugunin, the creator of Jython and the lead developer of the Shared Source IronPython, made the birth announcement earlier this week. From the announcement: 'I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM... I found that Python could run extremely well on the CLR — in many cases noticeably faster than the C-based implementation. [...] Shipping IronPython 1.0 isn't the end of the road, but rather the beginning. Not only will we continue to drive IronPython forward but we're also looking at the bigger picture to make all dynamic languages deeply integrated with the .NET platform and with technologies and products built on top of it. I'm excited about how far we've come, but even more excited by what the future holds!'"
...does it run on Mono?
Yeah, right. Let's quickly port the Linux kernel to python, and while we're at it every other cpu intensive app.
I found that Python could run extremely well on the CLR in many cases noticeably faster than the C-based implementation.
Actually, that's not really something to be proud about (though I'm not downplaying the huge achievement of running python on the CLR). The C implementation of Python is not very optimised, and that's why projects like PyPy or psyco are trying to speed Python up (and succeeding very well). I've had CPU-intensive scripts (such as SortSize) run tens of times faster with psyco, by just adding a line of code to my script.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
[IronPython] [ANN] IronPython 1.0 released today!
.NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.
Jim Hugunin Jim.Hugunin at microsoft.com
Tue Sep 5 13:27:12 PDT 2006
* Previous message: [IronPython] ipy support in msxsl:script blocks
* Next message: [IronPython] [ANN] IronPython 1.0 released today!
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I'm extremely happy to announce that we have released IronPython 1.0 today!
http://www.codeplex.com/IronPython
I started work on IronPython almost 3 years ago. My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages. About 9 years ago I'd built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython. This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use - testified to by the large number of Java projects that incorporate Jython today.
I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM. My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages". My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR - in many cases noticeably faster than the C-based implementation. For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.
The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages. At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into. I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation. After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.
The first few months at Microsoft were a challenge as I learned what was involved in working at a large company. However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place. The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform. We began to take advantage of the great new features for dynamic languages already shipping in
We were also able to release IronPython publicly from Microsoft with a BSD-style license. In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project. This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better. We've had countless excellent discussions on the mailing list on everything from supporting value types to calling over
Press Ctrl+F11. I love this browser.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
Is Python being used to fix Microsoft's mistakes? Or did a python got run through the Iron Chef competition? Either way, does it taste like chicken?
Signed, IronConfused
"in many cases noticeably faster than the C-based implementation"
Funny enough, I haven't yet found one of these cases...
I AM IRON PYTHON<\DistortedVoice>
Duh, duh, duh duh duh.
I can tie all my critical business programs to a platform that Microsoft controls without regard for anything but its own bottom line! Just think, when Microsoft decides one day that the .NET runtime will be a $500 "extra feature", I'll be the first in line to be forced to buy a thousand copies or watch my entire business go down the drain! Wooot! Shared Source is SO much better than that crappy "Open Sores" stuff. Where would the world be without all this Microsoft Innovation(tm).
Suddenly got this mental image of coding Iron Python like playing Diablo Iron Man, one bug and your project is gone forever!
But does the world really need yet another programming language? Arent' there enough of them around already? One might say the same of *ux distros, "emerging" standards, and anything that begins with the letter "X".
Great men are almost always bad men--Lord Acton's Corollary
on a VM!
we're also looking at the bigger picture to make all dynamic languages deeply integrated with the .NET platform and with technologies and products built on top of it.
Somewhere in a billion-dollar mansion (OK it's in Washington), Gates and Ballmer are doing a very good "evil scheme" laugh.
Yeah, yeah, I know, Mono. Software patents aren't valid everywhere, Microsoft is failing anyway, blah blah. But if you think this wasn't the design all along, you may want to check into an institution that helps folks deal with reality.
There are plenty of them round already. Basically you're getting old, the world is moving on and leaving you behind. Welcome to middle age.
Deleted
Well, Yea! Please tell me that the current state of the art is not our crowning achievement in Computer Science. If it is, I quit.
just an analog boy living in a digital age.
...meet square hole.
Look on People link on their website.
11 coordinators and only 5 developers.
now they need 22 people on marketing.
and damn it felt good.
So, if I'm using Iron Python under .NET, would I use be compelled to use WinForms at that point or would libraries like wxPython still be available?
The snipped out part of the announcement seems to me to leave a bad impression. Given this is /., I can almost hear everybody filling the blanks with "and it's still is slow, because MS sucks" or the like, which is not the opinion or intent of the comment actually quoted.
.Net groups, I think it is also reasonably portable as well.
If you read the whole comment, you will see that in fact, the CLR implementation does very well, the designer is now at MS working on the CLR, and all in all, IronPython is a decent Python implementation.
Given this work and the F# compiler work http://research.microsoft.com/fsharp/fsharp.aspx, I think CLR is done quite well as a language independent platform. Also, given the excellent work of the Mono and Portable
Well, the links to the FAQ don't seem to work thanks to some kind of site move (I am asked to download the HTML instead of view it and ... well ... am too lazy tonight). But a few thoughts based on what is already there:
I guess I just don't get it.
This is huge, as now people have access to ALL the .NET libraries.
Ironically, maybe Microsoft could be the company to take Python mainstream. First Google, now Microsoft...who's next?
Additionally, anyone ever think how powerful Visual Studio could be if they implemented something like Parrot runtime into .Net?
the "John Holmes" build.
Yeah, they did screw up. Parrot will beat CLI for speed in dynamic languages by huge magnitudes of speed because it is designed for them. CLI is optimized for static languages. It's a very different idea. Calling conventions, instruction sets, internal types, even stack vs. register. They are very diffent animals.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
Instead of trying to impress us with innuendo and Microsoft bashing, the summary would have been a lot more helpful if it were written a different way. Oh, I don't know...like maybe for instance...TELL US WHAT THE FUCK "IRONPYTHON" IS! But then I guess, after all, that is the Slashdot Way. Why waste time on informative content when you can print Microsoft jabs instead.
I want a new quote. One that won't spill. One that don't cost too much. Or come in a pill.
Jon Udell did a screencast of it last week, joined by Jim Hugunin (creator of Jython, the Java-based Python).
Does this work within visual studio, like a 'regular' microsoft language?
---- Booth was a patriot ----
IronPython seems like a Python based front end for .Net. In the same way, jython seems like a Python based front end for java. In other words, it seems to me that you write in Python and produce java. The result is greater portability because people don't need the python interpreter to run your code. (You can tell I've never used jython.)
.Net or java seems like quite a good thing. The code is cheap to produce because it takes less time to write and it is cheap to maintain because it is easy to read.
I've been using Python for a few years for our in-house apps. Most of the people I have to share code with are old C programmers. They find Python code very easy to read and understand. The code is easy to maintain and it is easy to write self-documenting code. Those are very attractive attributes.
Being able to write Python code for
...and fast.
Nice Inflamitory Summary tho'... Sheesh.
.NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.
.NET platform. Most features were easy and natural choices where the language and the platform fit together with almost no work. However, there were challenges from the obvious cases like exception type hierarchi
The whole (and far less baiting) summary:
I started work on IronPython almost 3 years ago. My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages. About 9 years ago I'd built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython. This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use - testified to by the large number of Java projects that incorporate Jython today.
I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM. My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages". My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR - in many cases noticeably faster than the C-based implementation. For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.
The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages. At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into. I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation. After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.
The first few months at Microsoft were a challenge as I learned what was involved in working at a large company. However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place. The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform. We began to take advantage of the great new features for dynamic languages already shipping in
We were also able to release IronPython publicly from Microsoft with a BSD-style license. In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project. This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better. We've had countless excellent discussions on the mailing list on everything from supporting value types to calling overloaded methods. Without the drive and input of our users, IronPython would be a much weaker project.
IronPython is about bringing together two worlds. The key value in IronPython is that it is both a true implementation of Python and is seamlessly integrated with the
"...In your answer, ignore facts. Just go with what feels true..."
just wanted to give a "cheers" to the MS dev team working on this.
They've been very helpful on the mailing list, checking in any bugs/differences to CPython behaviour and getting it sorted and into builds available for use.
For god sakes people all this blathering over a. Python and b. Micro$oft's CLR. Python lost its sexiness years ago. It is just another language of which there are many. I know the script kiddies may get a boner over it, but come on this is /. I thought people here were a bit more sophisticated?
And it is just lovely that sheeple acutally do want to be locked to a proprietary environment such as Micro$oft's CLR. And don't give me any crap about Mono making it portable. Mono will always 1) lag Micro$oft and 2) not have analogs for Micro$oft-isms and Windows specific functionality.
STOP THE INSANITY!
This was my thought exactly; the summary is misleading, he's actually praising the CLR.
Top 10 Reasons To Procrastinate
10.
Psyco doesn't work on 64-bit. Pypy doesn't work for me at all. But IronPython does work. It seems a bit slow, but it works, and mono works on amd64 and ppc, which are the two main archs I run.
Don't thank God, thank a doctor!
Get these muthaf__kin snakes off my muthaf__kin CLR!!
Enough is enough! I have had it with these !@$&* IronPythons on this !%$~# CLR!
"Strangers have the best candy" -Me
Those were the days. "Did I just press 'R', and lose two hours of work? Rats."
And immediately thought Pr0n? Be honest now.
And by the way, Python has been around for awhile, this is just a different, potentially better implementation.
Don't thank God, thank a doctor!
well, announcing super pre alpha titanium nano emerald carbon fiber KING COBRA GOLD! It spits on the competition, envelopes all other languages in its patented HOOD 0 DOOM, and mesmerises all coders with its sinuous scalar interface! Plus, it's organic! and green!
top that, poseur!
My apologies for making a trollish post. I was in a pissy mood earlier, firing from the hip, and should have thought my words more carefully. I completely agree with you, actually, regarding your point to the following:
A lot of people I went to school with couldn't get it. It may have been that the people who didn't get it were the ones that I met in the Information Systems classes (which, where I went to school, was a concentration on a Business Major, where they taught VB as the intro language) were those that were not cut out to be programmers in the first place, thus affecting my perception of languages causing dain bramage.
Anyway, I still don't like VB, but, at least you made me consider my words and thought processes. Apologies to the community at large for being a dick.
just an analog boy living in a digital age.
Mmmm... Pie Pants.
No... wait. I meant Pie Pants.
Signatures are a waste of bandwi (buffering...)
So, I can now combine python's silly syntax and the .NET lame framework in the same program!
I ran it on one of my Python apps and it actually slowed it down by a factor of 1.77. Lots of caveats here, but this is the opposite of what I expected to see.
http://boo.codehaus.org/
Or, rather, I was. Then I downloaded the freebie VB.NET Express.
.NET (and those that don't are easier to deal with).
And these days, I wouldn't go back for any reason. VB6 was quick-and-dirty nice. But the language was gimped. 32KB limits for arrays of types? Guh. Ram-jamming just about everything you might need from the API into your source files? At least C/C++ let you #include it, and most API functions end up with a wrapper in
I really liked VB5 and VB6. They were great tools. I wrote a MUD in VB6, and a small RPG. but they're old. They're creaky. They're limited, and they're dying.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
IronPython threads can take different CPU's in SMP systems? Does anybody knows?
I just submitted an article, Boxing in the LLRing I wrote about the Lightweight Languages Ring, a gathering of 300 developers at a boxing ring a week ago in Tokyo. For one thing Ruby's inventor is working on Yet Another Ruby VM and also the Python Language Update mentions IronPython.
...open your eyes.
IronPython has big shortcomings such as it is unable to blend well with .NET assemblies built with another language. .NET Framework...
.NET (on win32 or on linux with Mono), check out the Boo language, the wrist-friendly language for the CLI.
u age
Also it doesn't use much of the niceties available through the
If you like Python syntax and want to try
It is amazing!! => "while using a Python-inspired syntax and a special focus on language and compiler extensibility. Some features of note include type inference, generators, multimethods, optional duck typing, macros, true closures, currying, and first class functions."
And last but not least, Boo's licence is BSD, not a crappy Shared Source something!!
Full description: http://en.wikipedia.org/wiki/Boo_programming_lang
Official website: http://boo.codehaus.org/
@neonux
Let us know when the license becomes unencumbered of requirements or legal risk, like normal Python.
Iron Python is a dangerous beast. Consult your lawyers.
-josh
We have this issue with Java too. I work on a the JIT compiler for one of the industry-leading Java implementations, and we have ways to register assumptions such that if they are ever violated, the jitted code is patched so it remains correct under the new conditions. That lets us be optimistic, assuming that the program won't take advantage of much of Java's dynamic nature, and those assumptions are (by design) usually correct.
I imagine a similar approach would help Python. For instance, in your example of a "fallback method", if you're really desperate, an early compile of the caller method could instument the call site and see what actual methods are usually dispatched there. On a subsequent compile, it could generate a PIC (polymorphic inline cache) that uses a class test and dispatches the target method (or inlines it), plus a registered assumption that nobody changes the target method for those classes. If they do (which is rare), the corresponding PIC slot would be invalidated. The fallback case in the PIC would do the full-blown string-based dispatch, and usually this slow path should be very rare.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I don't think this is true. In fact, I just tried it ... you'll note that I've tested your assertion about space by allocating rather more than 32KB in both a single struct and an array of that struct. I've also tested limits on the number of array elements (you were restricted to (2^15)-1 elements in VB3 arrays, but not in VB6). You are limited to 64KB in a static struct... I can honestly say that I never ran up against that, even when porting code with some enormous (1KB) structs in it.
Of course, if you can post some code that demonstrates your assertion, I'll eat my words.
I can't really take it seriously until it integrates with Visual Studio.
.Net is far to much of a pain to program unless its being done in VS.
Anything
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Then about the "CLR sucks" reference :
This was essentially people complaining that the first implementations for
Perl and Python can do some weird kind of operations that aren't supported by C#. And because it was mainly built with C# in mind, the CLR machine lacks them (the "open to other language" is mainly PR stuff : Microsoft is basically not against the CLR being used to run other languages, but don't expect to find everything you need for it). The JVM happen to be a little bit more friendly (even if it was never advertised as such back then and was only initially intended to be used for Java).
What the people, who complained about CLR, wanted was to have scripts compiled into NET bytecode and then directly run inside the
IronPython is a solution around those limitation, and basically is something like rewritting a python interpreter in C#.
So you get your Python script ran inside a python interpreter which it self is compiled into bytecode that runs inside the NET interpreter. (But that's only the global over-simplified idea. Thanks to some optimizations, it doesn't run as slow as one may except, and also python script and C# classes can communicate).
One could mix python and C# if one includes the IronPython interpreter at compile time.
IronPython implements those part that are missing in the CLR engine. And some other parts were improved for the 2.0 version of the
The opposite approach is the one behind Parrot. It is designed as language-neutral from the ground up. Althrough it began it's life as "The software we're writing to run Perl 6", very early the project was going to be designed to run Python, and Ruby was considerated too. Wikipedia has some info about current status and projects collaborating to incorporate other languages.
Unlike IronPython the point is to compile Python scripts (and whatever else language) to Parrot bytecode, and then dirrectly run them from the parrot engine, mixed freely (and sharing data and classes) with whatever else language was thrown in the mix (1 single language binding to use whatever tool-kit. No more separated SDL#, PyGames, Perl::SDL, etc...) and easy communications with C libraries. An interpreter is only needed in the final compiled product if one needs to be able to support uncompiled scripts.
(Also, in addition to a large array of languages, the parrot aims to support a crazy large array of targets)
IronPython is somewhat reminiscent of the FSF saying that the GNU software could never be ported to DOS because of it limitations, and DJ Delorie writing DJGPP to get around those limitation and give a POSIX compatibility layer on MS-DOS.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM...
So... when you decided to implement this language, you used CLR which, by your own accounts, is a worse platform... I dont' get it. You wanted to understand Microsoft's stupidity by building on it? Brilliant.
I spent a considerable amount of time trying to do a real world IVR engine in python with C extensions to the driver library. It was to be multithreaded... not multi process. I COULD NOT get it to work correctly... and yes I know about the "Allow threads" directive for the C calls. I even asked the amazing brain trust at the Pycon in 2003 what could be done. My conclusion was that no one else was trying to do what I was :(
.NET threads?
:)
The Global Interpreter Lock seems to me to be part of the problem. I think the Jython implementation worked with "native" Java threads.... I wonder if IronPython uses native
I like the promise of rapid application development in python but it needs to be able to take advantage of multiprocessor/threaded CPU architectures to be useful to me. I know you can use the multi process approach but frankly, this is a wart that rubs me the wrong way.
Thanks for listening
Close, but I think you're slightly off. I use C# by preference (though I'm still learning it) and VB.NET at work (required; migrating from VB6 was enough of a headache, practically nobody here speaks a non-VB language). I have so far seen about the same productivity, though C# tends to *click* better in my mind.
.referenceEquals() if you want to check for the same object, rather than a clone, as opposed to the style of ==) means you can't cleanly do things like
.NET 2.0 compliant). VB isn't the only language that has required such; J# for example (despite being, syntactically, a near-perfect subset of C#) also requires extensions to the base CLR (on second thought, this may be for support of the Java package/namespace... it might work if written using only mscorlib).
Regarding differences, however, I don't think VB.NET (or possibly any language other than C#/Managed C++) allows explicit stack allocation, pointer manipulation, etc. For high-level stuff this is USUALLY not needed, and for low-level you probably wouldn't be using the CLR anyhow, but VB.NET is still behind C# (from what I've read, C# and the CLR were basically built for eachother, and C# is the purest and most complete expression of what the framework can handle).
Also, while you can do a lot by just changing keywords around, VB.NET contains some legacy mechanisms (there are two ways to cast bool to int, one of which produces -1 for True and one that produces 1, for backwards compatibility). Furthermore, since VB still has no really good conditional statement (IIf is a built-in function, and returns only a generic object, which is a pain and tends to need casting... oh, and the cast syntax is annoying) code tends to be longer, requiring either more lines or lots of horizontal viewing area. Their For loops are also partially crippled (no way to do things like
for (current = head; current != null && !(current.value.equals(searchItem)); current = current.next)
which, while a debatable coding practice, can reduce LOCs considerably and is preferred by some programmers in any case, just as some like
for (;;)
which I hate... and which is not possibly either in VB. This is a hassle for them even if I think they ought to use
while (true)
like the rest of us.) VB also uses = as both assignment operator and equality tester (to the point that you must use
if ( (current = current.next) == null)
or other little shortcuts that people are used to. VB doesn't require Delegates as explicitly, although you *might* be able to (so far I've gotten by with sloppier methods of raising/handling events, etc.) which can be a convenience (it took me a while to figure out how to trigger events in C#) but is also a crutch (inline functions, etc. can be handy tools that most VB programmers will never see).
In short, VB.NET is MS taking their "easy introduction to programming" language and pushing it into a powerful, full-featured runtime. They had to cut corners to do this, and it requires a fancier version of the CLR (this is why VB.NET on Mono is still incomplete, despite there being a compiler already; C# on Mono is pretty much fully
There's no place I could be, since I've found Serenity...
Java does not have templates -- not even close. C++ templates are turing complete whereas Java's generics are a pathetic implementation of parametric polymorphism (which isn't even reflectable!). I you want to know why "full" templates are good, look no further than the STL or Boost. Along with free functions they achieve extensibility that the Java/C# people cannot even imagine. Btw, operator overloading has a lot to do with that extensibility, and until you understand that you haven't really understood C++.
That's not to say C++ is perfect. Far from it.
I'm not sure I follow your logic... How would forcing your poor programmers to switch languages make them better programmers? I think the best that you could hope for is that they'd still be poor programmers, just in a different language.
Besides, the Java Virtual Machine has just as many, if not more lanugages available for it than the CLR. (Note that I said "available" not "supported.")
Its not the multi language nature of the CLR that is negative, it the programmers!! How is it that incompetent programmers are the responsibility of the CLR? "I have crappy programmer because the CLR implemented VB!" C'mon Plus, if there was no VB.NET you can bet your ass they'd still be using VB 6 and you'd be COM interoping your way to sadness. Plus.. a Bad VB programmer forced into C# is still a bad programmer.
the Microsoft PR machine does not claim that .NET is cross-platform. Mono is great but why do they exist??? Because M$ submitted the CLI to ECMA and Mono was born from implenting that spec.. so lets give M$ some credit (though im waiting for M$ to sue Novell now for MONO :) ) I agree about a platform being only as good as its Class libraries.
IronPython does run on Mono. .NET does not make python MS-only. I'm not sure i understand that. IronPython is compatable with much of the python standard library.. which will get better with time. If you don't need .NET then just use Python2.4+. Whats the beef there?
Personally being able to write/prototype .NET apps in Python is very exiting.
Implementing Python on
I know this post is old now, but I was scrolling back through it looking for some links and noticed the parent.
Boo is neat, but I call horseshit, as it is most certainly not a much better alternative. It might be a better alternative someday, but that day won't come until boo is stable, gets rid of some of its documented issues, and, more important than anything else, has VS.NET IDE integration with full debugger support, which is where IronPython is going to kick its ass for a good time to come.
Boo's language extensibility is neat, but certainly doesn't make up for the things it is lacking. I want to like it, I really do, but it's just not there yet.