Ironclad 0.8 Released: Python C Extensions from IronPython
Ironclad is a project by Resolver Systems to allow the use of Python C extensions from IronPython. Ironclad provides a compatibility layer for the Python C API, allowing extensions to be imported from IronPython. The goal is to allow the use of Numpy within Resolver One spreadsheets, but Ironclad is open source and available under the MIT license.
The core developer of Ironclad, William Reade, has just announced the release of Ironclad 0.8. This is an important release as many extension libraries are now usable with Ironclad. In fact now you can run through the whole Numpy tutorial using the IronPython interactive interpreter! As usual, sources and windows binaries are available from the project page:
The core developer of Ironclad, William Reade, has just announced the release of Ironclad 0.8. This is an important release as many extension libraries are now usable with Ironclad. In fact now you can run through the whole Numpy tutorial using the IronPython interactive interpreter! As usual, sources and windows binaries are available from the project page:
I'm delighted to announce the release of Ironclad v0.8 -- the all-singing, all-dancing CPython API compatibility layer for IronPython -- available now from the Ironclad Project Page. Notable improvements over the last release include:If you're interested in the implementation details, William Reade has posted an explanation of how Ironclad manages object lifecycles over on my techie blog:Ironclad grows more stable and mature with every release, and I urge IronPython users to try it out and share their impressions: feedback, whether positive or negative, is always welcomed.
- Ironclad is now a neatly self-contained package -- just copy to your site-packages and 'import ironclad'.
- No more silly requirement to call ironclad.shutdown() when you're finished.
- A few performance improvements.
- Over 900 NumPy tests now pass: in fact, almost all the tests from the core, fft, lib, linalg, ma, oldnumeric and random subpackages.
- Over half the .pyds distributed with CPython 2.5 now import cleanly; some of them appear to actually work, including _hashlib and _elementtree.
Two questions:
ReplyDeleteWhat is the level of support for Ironclad with Mono on Linux and OS X?
I have this crazy idea of trying to get CPython extensions created with Boost.Python working in C# with Ironclad. Do you think this will ever work?
At the moment, Ironclad only works on 32-bit Windows; last time we checked, it was possible to build the redirection stub on Linux, but the C# project DllImports a few Windows-specific functions, so it certainly won't work out-of-the-box.
ReplyDeleteHowever, fixing this shouldn't be especially difficult: there's really a very small amount of platform-specific code, and I expect most of the work will be in finding out what the *nix equivalents are (and, er, getting round to actually doing it).
Re: Boost.Python... I honestly don't see why not, as long as they're using the proper API ;-). What extensions were you thinking of in particular?
Awesome!
ReplyDeleteHave you tried it with any of the pygame .pyd files?
Are you able to try that?
We haven't tried Ironclad with pygame - but it should be very easy for you to try. We'd be interested in hearing about the results on the mailing list.
ReplyDeleteI have a vague feeling that pygame uses ctypes to talk to SDL, and we don't have ctypes support yet, so I suspect it'll be some time before pygame works.
ReplyDeleteI *think* it is pyglet that uses ctypes and pygame uses extensions. May be wrong though.
ReplyDeleteHmm -- a simple pygame example imports fine (on SVN head -- it uses a couple of functions not implemented in 0.8) but fails when calling run_game.
ReplyDeleteSerendipitously, it fails in exactly the same way as another extension I'm interested in fixing but don't have direct access to, which is extremely handy :-).
wow, that's pretty cool.
ReplyDeleteLooking forward to having a play with the next release.
cu.
Sorry, I'm not sure if I understand completely. Does this mean that if I have a Python library X, that I can use it now from my IronPython program Y? If yes, is this a performance bottle-neck?
ReplyDeleteThanks in advance.
Hi knocte,
ReplyDeleteI'm afraid the answer to your question is maybe and maybe.
Several large libraries (most of numpy and Scipy for example) now do work with Ironclad - and performance is a lot better than we expected. I'm sure there is more work to do in this area of course.
If there are particular libraries you want to use then give them a try and let us know (on the Ironclad mailing list) how it goes.
Michael
Thanks for your answer.
ReplyDeleteSo, your "maybes" are just because IronClad's lack of maturity, but in theory it's possible right?
So, if I can call a Python lib from an IronPython program, can I bypass as well the IronPython program and call the python library from another non-DLR language (i.e. C#)?
You're right. As for using Ironclad from C#, it would certainly be *possible* - but Ironclad creates IronPython objects (instead of Python objects) so you would have to interact with the IronPython objects from C#.
ReplyDeleteThis is certainly possible but probably not what you want to do. If you are interested in giving it a go then this article will get you started on interacting with dynamic objects from C# (particularly the stuff about ObjectOperations towards the end):
http://www.voidspace.org.uk/ironpython/embedding.shtml
Of course IronPython in Action is a better resource. ;-)