“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 .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 hierarchies to the somewhat esoteric challenges concerning different methods on strings.” More here.
IronPython 1.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I think it’s pretty cool that they managed to do this.
Let’s hope the jython team can keep up with this.
Even if you’re developing in java or C#, it’s pretty useful to be able to bring up a python prompt and try things out without the need to create classes and compiling stuff.
i hope they’ve finished the visual studio integration, as last time i tried the beta, you ran some console app and it fired up a seperate gui from vs2005 in debug mode or something very weird.
can you just select a python project from the wizard now, like c#/vb/asp?
i’d like to see some info on using python libraries in c# (is that even possible yet?) and vice versa, as well as windows.forms, otherwise you might as well just using python for windows and not python for .net
i’d like to see some info on using python libraries in c# (is that even possible yet?) and vice versa, as well as windows.forms.
You can use Python libraries. No, you can’t use Python extensions written in C. However, most of the built-in extensions written in C (re, socket, struct, etc.) are re-implemented in C#.
For Windows Forms, this wiki page links to many articles on using Windows Forms from IronPython:
http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title…
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.
On wonders whether Parrot will outshine the CLR. Glad to hear that IP went BSD. Dare we hope for continued improvement in the licensing area from Redmond?
Microsoft has been using BSD for at least 5 years now ever since they started releasing ROTOR code to the public. BSD is a great choice for companies because it is very simplistic and doesn’t require a lot in the way licencing issues that the GPL might stipulate.
IP’s license is BSD-like, not BSD. The main difference is the patent-defense clauses. AFAIK, Rotor is not BSD licensed either, and is even more restricted than the GPL.
I could have sworn that ROTOR was BSD at some point in time, even if it is not right now.
Much like jython I just don’t get it. Read it, still don’t get it, what in a nutshell does this improve the overall landscape with?
IronPython is so cool. Basically it allows you to extend python and embed python within .NET programs. I realize that that is to some extent possible with CPython, but the real beauty is how integrated it is with .NET. From within IronPython, I can create a new window. I can populate it with controls. I can add events. I can do anything to it that I would do with C#, but I can do it dynamically. On top of that I can use it to add scripting to an existing program. Right now I’m developing a program in C#. I’m adding (actually, I’ve already done this) IronPython to it so that the whole program can be scripted. What’s neat about this is that I don’t have to spend hours creating the “Python Interface Layer” and such. I just include IronPython and it has access to all of my data structures. It can dynamically add and delete things from my data structures and can call into CLR compiled code very efficiently. It’s just plain slick.
To the end user it doesn’t add anything more than just Python capability to more programs. To the developer, it’s just so much better than CPython for integration and extension.
I don’t have to write an ecmascript interpreter for my program to use thanks to IBM.
Much like jython I just don’t get it. Read it, still don’t get it, what in a nutshell does this improve the overall landscape with?
Have to agree. All that’s happened with Iron Python and Jython is that a language and envronment has been reimplemented within a different envronment, written in a different language. It’s still Python though, and doesn’t actually improve anything. It’s just extra work.
In theory, with Jython and Iron Python you’re able to take advantage of Java classes and libraries and the .Net framework to do extra ‘things’ in ‘Python’. However, if you have to reimplement an entire language and environment to do that then it sounds like an awful lot of wasted effort. It would be better to use standard Python and use various packages to implement interoperability.
I found out about Jython many years ago when I was doing a lot with Zope and Python at the time, and I thought it sounded like a really cool idea. I then grew up and realised that it is one of those ‘cool‘ technical projects that sounds ‘cool‘ but has limited practical usage.
The most obvious way in which IronPython ‘improves the overall landscape’ is that it gives you a Python interpreter which can make use of .NET objects – is this not enough?
I can imagine a lot of scenarios where this might be useful, and I am sure many people already make use of IronPython for their purposes.
About the ‘wasted effort’ stuff – this is AFAIK a one-man research project, which gives Microsoft a lot of feedback about how the CLI can be improved for better handling of dynamically typed languages.
“About the ‘wasted effort’ stuff – this is AFAIK a one-man research project, which gives Microsoft a lot of feedback about how the CLI can be improved for better handling of dynamically typed languages.”
Well, it started as a “one-man research project”, but I gather from reading Jim Hugunin’s blog and the IronPython mailing list message board many MS guys joined the effort. And I don’t know that I’d qualify it as a “research” project anymore, it’s just as real as CPython and Jython for actual deployment.
But I agree that IronPython has been used to gather info on how to impove CLR for dynamic languages and that the effort hasn’t been “wasted”. 🙂
Another IronPython “goodie” (in addition to what’s already been mentioned above) is that IronPython is faster than CPython for in some cases (I assume that is’s slower in others), according to Huginun’s blog.
Edit: I prefer F#, myself. 🙂
http://research.microsoft.com/fsharp/fsharp.aspx
Edited 2006-09-06 16:12
Leaving aside the advantages of being able to access the entire .Net library, and any library developed for .Net, IronPython also improves on Python itself in several respects
* It uses Unicode by default. CPython uses Ascii by default, and only supports Unicode recently as a special type of String. IronPython is thus easier to localise
* Related to the first point, IronPython will compile files whose identifiers use non-ASCII characters if the file has an encoding comment such as “# -*- coding: utf-8 -*-“. CPython will not compile such a file in any case.
* Again related to localisation support, IronPython uses the locale-specific settings for printing numbers. E.g. the number 1,000,012.34 should in France be printed as 1.000.012,34. IronPython does this, CPython doesn’t.
* IronPython uses a more modern garbage collection system than CPython. Developers of CPython have to worry about circular dependencies due to it’s reference counting system, IronPython developers don’t.
* IronPython supports some regular expression syntax that CPython does not.
* IronPython catches String exceptions by value rather than type, making it possible to use an expresion in your catch clause
* IronPython raises a ValueError for very large exponents (for example, 10 ** 735293857239475) while CPython hangs trying to compute the number.
* IronPython supports ‘continue’ statements in ‘finally’ clauses.
In some respects, IronPython is a better version than CPython, particularly if you want people outside of the English-speaking world to use your applications. What’s more, IronPython apps appear to work on the Mono CLR, so it’s cross platform as well.
A full list of the differences can be found here: http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title…
>>
* Again related to localisation support, IronPython uses the locale-specific settings for printing numbers. E.g. the number 1,000,012.34 should in France be printed as 1.000.012,34. IronPython does this, CPython doesn’t.
<<
I’m not sure that it is a good idea to do this by default, this is a nice option sure, but doing it by default..
I’m not convinced that it is a good idea (and I’m French!).
Nice to know I’m not the only one. I guess the main part I don’t get is why would something be better in python? I’ll accept it’s a great platform, but better?
Does anybody know how IronPython compares to CPython performance-wise? And I mean in the real world, not those pystone benchmarks where IronPython claims to be 1.5x faster than CPython.
I did some benchmarks with non-trivial code (on Windows) and CPython seems twice as fast as IronPython (for apps that run for less than a few seconds, CPython is even faster). Has anyone else seen this behaviour?
I just perused the slashdot thread on this (complete with mindless MS bashing), and someone pointed out this very cool screencast where Jim Hugunin demoed IronPython for John Udell last week. The screencast shows IronPython working with WPF, C#, Monad (aka PowerShell), VB, and Visual Studio (as well as pure Python stuff). It’s very cool stuff.
Here’s the link to the screencast:
http://weblog.infoworld.com/udell/2006/08/30.html#a1515
Edited 2006-09-07 02:37