Ironclad 0.5 Released - Use numpy from IronPython

By Michael Foord -
Ironclad is an Open Source project created by Resolver Systems to allow you to use Python C extensions from IronPython. It is basically a reimplementation of the Python C API in C#.

William Reade, the main developer of Ironclad, has just announced the release of version 0.5.
The exciting thing is that with the latest release (and commenting out a single line in numpy) you can now import numpy from Ironpython and create and use integer arrays!

There is still a lot of work to do, but this is great progress.

From the announcement:

Our original goal for 0.5 was to import numpy, from IronPython, and do something with it. With one monstrous caveat, we have reached that goal; the problem is that you need to comment out line 532 of numpy.core.numerictypes.py before it'll import. That line reads "_unicodesize = array('u','U1').itemsize", and fails trying to construct a unicode array; however, since _unicodesize appears to be unreferenced, we feel reasonably comfortable ignoring it for now.

Once numpy is imported, you can create integer arrays and do a few things with them; of course, the number of things you can do is still dwarfed by the number of things you can't do. You can add, subtract and multiply integer arrays, and raise them to integer powers... and that's about it.

We will continue to work on numpy; immediate goals include getting floating-point arrays to print out as numbers instead of NaNs, hooking up the many missing PyTypeObject fields, and implementing more API functions as we encounter them. I don't have a very clear goal in mind for v0.6 as yet; making floating-point arrays work properly is obviously critical, but further steps are not yet clear. If anyone is particularly keen to start using numpy with IronPython, please get in touch; I'm keen to know what you want to do with it, so I can focus on features I know are valuable :).

 Ironclad targets IronPython 2 and although the underlying techniques should be cross-platform it currently only builds on Windows. Mono / Linux hackers welcomed!

UPDATE: It turns out that _unicodesize is no longer used, and in response to us asking what it is for it has now been removed...

Comments

Post a Comment

Popular posts from this blog

Extending Abobe Flash Player and AIR with Python and Ruby

By Michael Foord -
An intriguing blog entry about an Adobe experimental project. It is a C/C++ cross- compiler for the flash player and AIR. This means that you can (will be able to?) cross-compile the Python / Ruby/ lots of other language runtimes and then run them in Flash. The blog entry contrasts this approach to the DLR which requires the re-implementation of dynamic languages - hence IronPython and IronRuby. The project is already beyond proof-of concept, they even have Quake III cross-compiled and running in Flash. Extending Adobe Flash Player and AIR with C/C++ Cross-Compiler Quake 3 has already been ported to managed code , but this is even more impressive. Whether the Python interpreter can be cross-compiled to run on top of another runtime (with completely different basic types), without changing the language semantics at all, has yet to be proved - but it is a very interesting project. (It also means that Python/Ruby will possibly be enabled only by additional optional downloads - but don'
Read more

Should Python Projects Support IronPython and Jython?

By Michael Foord -
The maintainers of the Spring Framework for Python ( Spring Python ) wonder how much of a priority it is to have compatibility with platforms other than CPython. In other words, should they support IronPython and Jython - and if so what should they do about their C extension dependencies? This question sparks a good discussion and is relevant to many other Python projects and applications: Need for supporting IronPython, Jython? " One of the topics on my mind recently, as we consider refactoring the core container, is how we ensure that when we introduce internal dependencies, such as possibly the Amara libraries for XML processing, what secondary constraints we might be introducing. " " For example, Amara represents a very pythonic and therefore simple to read and use approach to developing XML processing, such as our very own XML application configuration parsers. So from that perspective, things are very attractive. But then you ask the question, "can I run this
Read more

Further Adventures of the Debugger

By Michael Foord -
Harry Pierson (Microsoft IronPython PM) has been experimenting with writing an IronPython debugger ( ipydbg ) on top of the .NET MDbg APIs. When we last left him , he had implemented Just My Code (JMC) support allowing you to step into IronPython code. Since then he has made a lot of progress including a colourful REPL (interactive console) and solving some difficult problems around getting to real values behind boxed IronPython variables (needed for showing local variables). He has blogged extensively on what he has been up to (more recent posts last): Showing Source Code Colorful Console IronPython ConsoleColorMgr (the colorful console code pulled out into a separate IronPython module) A Little Hack...err...Cleanup Getting Local Variables Displaying Values Command Routing Getting Arguments REPL Console A lot of functionality is now present. In the command routing entry Harry outlines the seven commands supported by the debugger so far: Continue, Quit, Show Stack Trace, Show Locals,
Read more