[Numpy-discussion] Request for advice: project to get NumPy working in IronPython
Tue Oct 16 08:17:43 CDT 2007
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:
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
> 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.
MD & CTO, Resolver Systems Ltd.
+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
More information about the Numpy-discussion