IronPython opens up the world of .NET to Python programmers. It’s not as good yet at opening up the world of Python to .NET programmers.
It is easy to write .NET applications in IronPython. I typed in some sample code within a few minutes of installing IronPython and made a very simple Windows application. But I was also interested in going the other way around. I was hoping to use IronPython to expose Python library functionality (specifically SciPy) to C#. This may be possible, but it’s swimming upstream.
There are two issues. First, calling Python from C# is more complicated than I’d expected. In hindsight it makes sense that it should be easier to call statically-typed languages from dynamically-typed languages than the other way around. I wouldn’t be surprised if IronRuby has an analogous problem. Second, even if you’re only using IronPython, not calling it from another language, there are problems calling some Python modules.
I asked a question about SciPy and IronPython on StackOverflow and got two excellent answers. First, “NXC” explained that modules written in pure Python will work with IronPython, but modules written in C will not work directly.
Anything with components written in C (for example NumPy, which is a component of SciPy) will not work on IronPython as the external language interface works differently. Any C language component will probably not work unless it has been explicitly ported to work with IronPython.
That’s disappointing, but it makes sense.
Second, “wilberforce” pointed out an open source project, Ironclad, that might fill in the gap.
Some of my workmates are working on Ironclad, a project that will make extension modules for CPython work in IronPython. It’s still in development, but parts of numpy, scipy and some other modules already work. You should try it out to see whether the parts of scipy you need are supported.
Related links:
Something to note though is that Python C extensions generated using SWIG (not numpy, but many others) can be quite easily opened up to both Jython and IronPython. We’ve done this with OpenBabel, a C++ library for chemistry. The route we use is to generate CPython bindings for CPython (naturally!), Java bindings which can be used from Jython and C# bindings which can be used from IronPython.
Calling Python from C# needs to be done through the hosting API. Python classes are created at runtime rather than compile time, and unless you subclass a .NET class a Python class isn’t even a static class (because Python classes are simply so much more dynamic than C# classes).
Nonetheless interacting with dynamic objects from C# can easily be done. See this article for some examples:
http://www.voidspace.org.uk/ironpython/hosting_api.shtml
IronPython in Action is an even better reference on this subject… :-)
Michael Foord
VS2010 and .NET 4.0 will have better DLR integration between IronPython and C#. Hang in there.
C# 4 will make interacting with dynamic objects substantially simpler (at the cost of type-safety of course) but you still need to go through the IronPython hosting API to *get* the dynamic objects. Not difficult but C# 4 is not quite the magic bullet in this area that some people think it is…
IronPython is not Python, just a better Visual Basic.NET.
@rgz you are very wrong about IronPython. :-)
Okay, I’m wrong, just explain me why.
You can’t run Python code and run it in IronPython unless you stay clear of any modules either those missing from the standard library or pypi, you can’t pip or easy_install things around, nor you can run IronPython code in Python that uses any .net libraries. Your project is basically married to either one platform or the other.
You can’t download an run eggs so you can’t say “I can run python” with only IronPython installed.
So the only good reasons for IronPython are because you needed a dynamic language and dynamic VB.NET did’t cut it or you want to provide scripting and are adamant python is the way to go. (Or just because)
Now, there is a Python like language that allows you to ignore types if you want, and has type inference for when you need it, it is way easier to adapt to C#/VB.NET and has some extra features, its called Boo.
Now since IronPython is hopelessly incompatible with Python, why not using Boo? I just don’t see the appeal. But don’t worry we just agreed I’m wrong…
“You can’t run Python code and run it in IronPython unless you stay clear of any modules either those missing from the standard library or pypi,”
Most of the standard library and huge swathes of the libraries on PyPi *do* work, so your argument is mainly moot anyway. You claim you can’t ‘download and use eggs’ but that is basically untrue (unzip them and add their directory to the path).
I assume you think Jython isn’t Python either?
You are hopelessly confusing Python the language with Python libraries. You can’t use Python libraries that depend on Linux functionality on Windows – and vice versa. By your rules Python isn’t Python as there are plenty of libraries that don’t work on any specific platform!
VB.NET *isn’t* very dynamic and if you like Python and want access to functionality in the .NET framework, IronPython is a fantastic implementation of Python.
Michael Foord, do you really mean that standard library is not an essential part of any language? Well, it is. If you cripple the library, you cripple the language.
In addition to the excellent standard library, *real* Python is an extremely dynamic language. It allows you to implement anything from distributed programming framework, code migration libraries and full-blown debugger for the language itself. Everything by using pure Python and nothing more. (If you say that in .NET people should use .NET debugger, you totally lost the point.) But you can’t even use sys._getframe() in IronPython. Probably I should not even ask about changing the bytecode of functions on-the-fly.
Giving up some of the reflection and dropping the low-level runtime modifiability would kill the Python even if the standard library would work perfectly. Those things make real Python one of the most powerful dynamic languages there is.
The best syntax and semantics do not make the best programming language alone. It also takes the best runtime and the standard library, too.
rdname, I hesitate to speak for Michael Foord, but my impression is that he is more committed to Python than to .NET. For a while there he was doing both in the form of IronPython, but I believe he is doing less IronPython these days.
@John
I’m still working with IronPython but doing Silverlight development rather than desktop application development.
@rndname
The fantastic thing about IronPython is that you get *two* standard libraries – both the Python standard library *and* the full range of .NET libraries.
Yes Python is a highly dynamic language – and you lose none of that dynamism by switching to ironpython. Introspection works just as you would expect – and in fact needs to in anything calling itself an implementation of Python. In IronPython 2.6 Python stack frames (which Guido himself has called an implementation detail) even work. Pdb works as well (*and* you can use .NET debugging tools).
With a tool called Ironclad you can even use many Python C extensions with IronPython.