Posts tagged as:

IronPython

Numerical computing in IronPython with Ironclad

by John on March 19, 2009

In a previous post, I discuss my difficulties calling some Python modules from IronPython. In particular I wanted to call SciPy from IronPython and couldn’t. The discussion following that post brought up Ironclad as a possible solution. I wanted to learn more about Ironclad, and so I invited William Reade to write a guest post about the project. I want to thank William for responding to my request with a  very helpful article. — John

Hi! My name’s William Reade, and I’ve spent the last year or so working on Ironclad, an open-source project which helps IronPython to inter-operate better with CPython. Michael Foord recently introduced  me to our host John, who kindly offered me the opportunity to write a bit about  my work and, er, how well it works. So, here I am.

To give you a little bit of context, I’ve been working at Resolver Systems for several years now; our main product, Resolver  One, is a spreadsheet with very tight IronPython integration. We like to describe  it as a “Pythonic spreadsheet”, and that’s clearly a concept that people like.  However, when people think of a “Pythonic spreadsheet”, they apparently expect it  to work with popular Python libraries — such as NumPy and SciPy — and we found that IronPython’s incompatibility put us at a serious disadvantage. And, for some reason, nobody seemed very keen to  solve the problem for us, so we had to do it ourselves.

The purpose of Ironclad is to allow you to use Python C extensions (of which there are many) from inside IronPython without recompiling anything. The secret purpose  has always been to get NumPy working in Resolver One, and in release 1.4 we finally  achieved this goal. Although the integration is still alpha level, you can import  and use NumPy inside the spreadsheet grid and user code: you can see a screencast  about the integration here.

However, while Resolver One is a great tool, you aren’t required to use it to get the benefits: Ironclad has been developed completely separately, has no external  dependencies, and is available under an open source license. If you consider  yourself adequately teased, keep reading for a discussion of what Ironclad actually  does, what it enables you to do, and where it’s headed.

[click to continue...]

{ 2 comments }

IronPython article on CodeProject

by John on March 11, 2009

It’s difficult to use SciPy from IronPython because much of SciPy is implemented in C rather than in Python itself. I wrote an article on CodeProject summarizing some things I’d learned about using Python modules with IronPython. (Many thanks to folks who left helpful comments here and answered my questions on StackOverflow.) The article gives stand-alone code for computing normal probabilities and explains why I wrote my own code rather than using SciPy.

Here’s the article: Computing Normal Probabilities in IronPython

Here’s some more stand-alone Python code for computing mathematical functions and generating random numbers. The code should work in Python 2.5, Python 3.0, and IronPython.

Related post: IronPython is a one-way gate

{ 4 comments }

IronPython is a one-way gate

by John on February 26, 2009

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:

Getting started with IronPython
Getting started with SciPy (Scientific Python)

{ 11 comments }

Getting started with IronPython

by John on February 19, 2009

I’ve just started experimenting with IronPython, Microsoft’s implementation of Python built on .NET. You can download IronPython from CodePlex either as an MSI installer or a zip file of binaries. I installed it from the zip file on one computer and from the MSI on another. I highly recommend the latter.

Installing from the zip file

The CodePlex download page has three files:

  • IronPython.msi
  • IronPython-2.0.1-Bin.zip
  • IronPython-2.0.1-Src.zip

My first thought was that I wasn’t interested in compiling IronPython from source, so I’d just download the bin file since it was smaller. I downloaded it, unzipped it, and copied it over to my C:\bin directory. (I have a habit of installing languages in C:\bin to placate software that assumes paths don’t contain spaces.  For example, if you install R in the default C:\Program Files location, some add-ons will break.) The typical command line “hello world” program worked just fine. The example from the readme file on how to pop up a window using WinForms worked fine as well. But my attempt to use a standard library by typing import urllib didn’t work. The standard Python modules are not in the search path by default. The tutorial that comes with IronPython explains how to fix this.  I added the following two lines to C:\bin\IronPython-2.0.1\Lib\site.py and then was able to use standard modules like urllib .

import sys
sys.path.append(r"C:\bin\Python25\Lib")

I had a non-ferrous version of Python installed already in C:\bin\Python25 so I just reused those files. The tutorial explains where to get the standard library files if IronPython is the first Python you install.

Installing from the MSI file

On a different computer, I downloaded the MSI file and ran it. This was a much nicer experience. The installer has a check box to run NGen on the .NET code in IronPython. I checked this box assuming it would make IronPython run faster in the future.

The standard modules worked immediately with no configuration on my part.The installer created a sophisticated site.py file that builds the path on start-up. Presumably this site.py file will add new modules to my path as I install things in the future.

{ 1 comment }