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.

Comments

what a combination!

[Anonymous Coward]

Mediocrity and complexity, together at last! Now available in family size!

This post will be modded down in 5.. 4.. 3..

Re:what a combination!

[Anonymous Coward]

Don't ask me, I went WTF!?!?! when someone did a basic interpreter in java....

Asked and Answered

[Anonymous Coward]

"Is Python, Mono and GTK# the new killer combo for rapid Linux desktop application development?"

In a word, NO!

Dear god why?

[shaitand]

Personally I'm not crazy about Python. And then you add this .net thing into the picture, I'm especially not crazy about that.

But then, to top everything else off, you add a version of python for .net written by a Microsoft employee?

Re:Dear god why?

[bdash]

The reason that Python on .NET is of interest is due to past research 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.

Re:Dear god why?

[Anonymous Coward]

I wonder how it handles continuations and rewriting classes on the fly or building them at runtime, like you might find in really dynamic languages (Ruby comes to mind).

Does it do eval() efficiently I wonder?

Re:Dear god why?

[Anonymous Coward]

But aren't you comparing an interpreted virtual machine implementation to a JIT compiled implementation? It doesn't seem a very fair comparison. Another guy earlier in the discussion also claimed that the CLR would need extra instructions to get good performance on dynamic languages.

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

[Skeezix]

I mentioned this morning that it seems 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.

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.

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 Passport. Or, about how C# sucks and Java r00lz.

But for me, .NET is way cool because of what you described so well. Perhaps I've been doing a poor job at saying why .NET is cool, or maybe it just takes a long time for any real information to get through the skulls of people here. :P

And embrace and extend? Not much of an issue. It doesn't matter to me if all of a sudden MS completely rewrites .NET, C#, whatever- we still have Mono. And even if it wasn't binary and API (e.g. WinForms) compatible with MS's .NET, we still have something really cool that is incredibly useful.

Re:It's the bindings, stupid

[Anonymous Coward]

> button.Clicked += hello_world

Am I the only one that doesn't like the "+=" idiom for event handlers?

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.

Re:Mono should go somewhere with this

[Anonymous Coward]

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.

Actually they care enough to hire him to work on improving the CLR for dynamic languages.

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.

Their has always been interest in adding better support for dynamic languages in mono and I expect it to improve now that their is a better test case.

Bad Name

[shitface]

Perhaps I am nitpicking but the name IronPython gives me the false impression of enabling Python to run on bare metal. The name would be much better suited for a Python system that compiled down to native code, sigh.

I have been kicking around some Python system implementations. Basically, people like to compare Python to Lisp and there are some decent (better than the "native C Python implementation") Lisp systems out there. Connect the dots.

Peace out.

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?

[Anonymous Coward]

don't forget java (jython)

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 right? Oh I am sorry, 5.

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.

Boo, a Python-derived language

[Anonymous Coward]

Thought it could be of interest of slashdotters: there's a language called Boo being developed for the CLI. It looks pretty sweet to me: very similar syntax, with the addition of a smart static typing system among other features.