[Numpy-discussion] Request for advice: project to get NumPy working in IronPython

[Giles Thomas]

We've created a Google Group to discuss this project, and if anyone's 
interested in contributing or advising, you're very welcome to sign up: 
<http://groups.google.com/group/c-extensions-for-ironpython/>

My replies to everyone's comments below:

David Cournapeau wrote:
 > Giles, maybe you could see with the pypy people if they can give you 
some advice, too

Thanks for the pointer - I'd heard of PyPy, but it hadn't occurred to me 
that they have valuable knowledge about how to do this kind of thing - 
obvious now you point it out :-).  I'll get in touch with them.

 > According to pypy developers, the best way to extend python in C is 
to use ctypes:

There was an effort to get ctypes working with IronPython a while back - 
the CPython Reflector by Sanghyeon Seo that Albert Strasheim mentioned 
-  Seo has just joined our mailing list, so we'll certainly start a 
discussion about that.

 > Christopher Barker wrote:
 > > Is there a C# <-> C (or, I guess, really a .net <-> C ) binding
 > > mechanism? Like JNI for Java?
 > I don't know much about the whole .Net thing (CLR, in this case), but
 > there is the p-invoke mechanism for that

P/Invoke is indeed the normal way to link C# with C; we use it in our 
software on those (luckily rare) occasions when we have to step outside 
the .NET world and talk to the basic Win32 APIs.  It's pretty easy to 
do, and our initial thoughts about the best way to integrate IronPython 
with NumPy were that we would use P/Invoke to call into the C library (I 
agree with Travis E. Oliphant that trying to convert the existing C to 
C# would be a Bad Idea).  Using P/Invoke would give us a very 
rough-and-ready .NET API, which we could then wrap with a Python library 
that <handwaving>interfaced with the existing CPython library in some 
manner</handwaving>.

 > I don't know the performance impact.

I don't think P/Invoke slows down the running of the C code, but of 
course calls from .NET to native code are quite slow.  My expectation so 
far has been with most Python code using NumPy, the number-crunching 
will happen at the native code level, with relatively few switches 
between languages - that is, it is a "chunky" rather than a "chatty" 
API.  Is that a reasonable assumption?

> The best would be of course a solution which enables interop, 
> so that if later, people want to use the work gone into numpy 
> for IronPython, people do not have to start everything from 
> scratch for say Jython or something else. But maybe this is 
> too big of a task.


We're aiming to try to solve the "simple" case of one Python 
implementation, one C extension to start off with.  Our intention was to 
then look at handling a couple of other extensions, to broaden the 
solution more toward a general solution for loading C extensions into 
IronPython - I agree that we could usefully also broaden it to handle 
other Python implementations.


Regards,

Giles

-- 
Giles Thomas
MD & CTO, Resolver Systems Ltd.
giles.thomas at resolversystems.com
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/ 

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK