IronPython-0.6 For .NET/Mono Debuts

Sunspire writes "IronPython, a Python implementation for the .NET and Mono platforms, has just released its latest version, IronPython-0.6. Touted features include speed, with IronPython being supposedly faster than the native C version of Python, and CLR integration giving full access to the .NET and Mono libraries while still being fully dynamic like regular Python. Is Python, Mono and GTK# the new killer combo for rapid Linux desktop application development?" We previously covered IronPython back in May.

Re:Dear god why?

[bdash]

The reason that Python on .NET is of interest is due to past research [activestate.com] implying that the CLR is not a suitable environment for dynamic languages. IronPython shows that it this is not the case, and that in many situations the generic CLR may provide faster execution times than language-specific virtual machines.

This is superb

[fozzmeister]

Does anybody know if you can access your Python classes from .NET?

This guy is actually working for Microsoft and its being released under the Common Public License. See MS isn't always the evil empire.

Re:This is superb

[bdash]

From the article:

The more time that I spent with the CLR, the more excited I became about its potential. At the same time, I was becoming more frustrated with the slow pace of progress that I was able to make working on this project in my spare time.

Jim Hugunin developed IronPython during his spare time, not as part of his work for Microsoft. The fact that it is being released under an open-source license is no reflection on Microsoft's status as "the evil empire".

Re:This is superb

[fozzmeister]

Wow the power of selective editing, the sentence after the one you quoted is:-

I think that I've found the ideal way to continue working to realize the amazing potential of the vision of the CLR. I've decided to join the CLR team at Microsoft beginning on August 2.

Make your own judgement.

Re:This is superb

[bdash]

As far as I am aware August 2nd is in the future. Though Jim Hugunin may have been employed by Microsoft while he wrote IronPython, he was working in a group unrelated to .NET and the CLR, and he wrote it in his spare time. I fail to see how this ties Microsoft to his decision to release IronPython as open-source software.

Re:This is superb

[Anonymous Coward]

Though Jim Hugunin may have been employed by Microsoft while he wrote IronPython . . . he wrote it in his spare time. I fail to see how this ties Microsoft to his decision to release IronPython as open-source software.

Well, it rather depends on whether he was employed by MS at the time. If he was, then his contract almost certainly stipulates that all his code (even what he writes his spare time) are belong to them.

Re:This is superb

[Directrix1]

I fail to see how such a generally linux-centric site can not see pitfalls in trusting a Microsoft employee to continue to develop something that works in linux and windows. I'm not giving up my python interpreter just yet.

Re:This is superb

[Skeezix]

I mentioned this morning that it seems [pubcrawler.org] he's going to Microsoft to work on IronPython and improve the CLR for dynamic languages. It's hard to say what Microsoft's plans would be for IronPython, but improving the ECMA CLR for languages such as Python sure sounds exciting.

It's the bindings, stupid

[Majix]

One real world problem I see IronPython fixing is the availability (or lack thereof) of up to date bindings for the language. Since IronPython targets the CLR you do not need to write your Python specific bindings for GTK, gnome-libs, etc. anymore. Instead, any Mono language can use the Mono targeting GTK#, gconf#, atk# and so on. This doesn't just affect Python, all smaller languages like Ruby or Haskell, heck even Perl and PHP, could benefit from using a shared set of bindings. Even if they already all have their own versions of GTK, when you want to introduce a new library like gnome-vfs everyone has to go and write their own version of it, which is just wasteful.

Also, Novell throwing their weight behind GTK# gives me confidence that we'll still be receiving updated versions of it a few years from now, which is important when you're trying to sell your PHB on the idea to base your next project on the bindings.

Here's a quick "Hello world" program in IronPython and GTK#, tested with Mono 1.0. It certainly looks slick. Note the neat way of attaching the function callback to the button's clicked signal, when you're coming from the C version of GTK you really appreciate small things like that:

import Gtk

def hello_world (o, args):
print "Hello world!"

Gtk.Application.Init()
window = Gtk.Window ("Hello world!")
button = Gtk.Button ("Hello!")
button.Clicked += hello_world
window.Add (b)
window.ShowAll ()
Gtk.Application.Run ()

Re:It's the bindings, stupid

[clintp]

So slick in fact, I don't even program in Python (much less IronPython) or GTK and think I've found a bug. Shouldn't:

window.Add (b)

be

window.Add (

button)

Otherwise I don't see how the button gets associated with the window.

Re:It's the bindings, stupid

[RevAaron]

Since IronPython targets the CLR you do not need to write your Python specific bindings for GTK, gnome-libs, etc. anymore. Instead, any Mono language can use the Mono targeting GTK#, gconf#, atk# and so on.

You know, it's about bleeding time some else figured this out. Since .NET and Mono were announced, I've been talking about how great this is for the community. Most of this time, people here would just go on about how .NET sux0rs because MS is going to spy on what you do in the bathroom because of Pass

You're not the only one

[GCP]

Yes, I've even heard MS employees complain about this. Unlike Java, C# has operator overloading, which lets you do lots of useful things, but also lets you go overboard, as in this case. Though this is Python, it's using an overloaded "+=" operator to an event handler to an event, the same way that C# does it.

I certainly think

button.Clicked.AddHandler(hello_world)

would be clearer, but the use of delegates in .Net/Mono languages is a nice improvement over Java's interface-based event handling.

Very Interesting

[blueZhift]

As I been dragged almost kicking and screaming into more Python, via a Zope project I'm working on, I find this very interesting. I've been fascinated with the potential of the .Net platform for a while now, particularly because of its ability to support a wide range of languages via the CLR. Now with Mono coming along IronPython, I've got some new things to play with!

I just hope that Jim's new job at Microsoft won't bring the project to halt.

Mono should go somewhere with this

[Qwavel]

This might be faster than C Python, but it is still slow compared to other dotNet apps. For many applications and purposes this doesn't matter, but it does imply that the CLR really isn't very good for dynamic languages.

Actually, the CLR could be great for dynamic languages, but it would require adding some new instructions, and MS isn't willing to do this so long as dynamic languages are not important to them.

For Mono, and the Linux community, however, dynamic languages are very important, so Mono should add the necessary support to make these languages work better. This could be done without affecting Mono's ability to run MS dotNet apps.

And anyway, Mono won't really be compatible with all the MS API's unless they license technology from MS, so we need to accept that Mono could be a great development environment for the OSS community, but its not going to run all your MS apps for free. BTW, I'm not referring to the present, I'm referring to the day when MS decides it's time to enforce their patents for ASP and Forms.

parrot?

[bcrowell]

How is the parrot implementation of Python coming? How do people see the pros and cons of the two VMs? Are we going to have three different implementations of Python running around (C, .Net, and parrot)?

Re:parrot?

[clintp]

If the lists are any indication, I think at OSCON Parrot will be running a subset of Python. Not well enough to win the Pie-a-thon (google for it) but well enough to demonstrate that it's feasable.

Re:parrot?

[CableModemSniper]

You mean 4 [jython.org] right? Oh I am sorry, 5 [stackless.com].