On Mon, Oct 26, 2009 at 5:47 AM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/26 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 5:12 PM, Michael Foord <fuzzyman@gmail.com> wrote:
2009/10/25 Guido van Rossum <guido@python.org>
On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman@gmail.com> wrote:
Well, you can use Python C extensions with Ironclad [1]. The maintainer hopes to port the core to Jython at some point as well.
What do you personally think of Ironclad? And (separately) of those hopes?
It seems like it ought to be an impossible task - reimplementing the Python C API for another platform. It actually runs surprisingly well (astonishingly) and I know of at least one bank in London now using it in production. The Ironclad implementation reuses the Python C source wherever possible in order to minimise the core that actually needs implementing.
A *large* number of the Numpy and SciPy tests pass with it (~1000 of each last time I checked) and *generally* performance is pretty good. I'd like to see Ironclad in wider use.
The hopes of the Ironclad maintainer to reimplement the core for Jython is certainly *plausible*, but it of course depends on him finding time in the future.
Personally when I write IronPython code I try to avoid a dependency on C extension modules as it seems to me that the *point* of IronPython is to make use of the .NET framework (otherwise you might as well just use CPython). Where Ironclad is being used is where people want to interface existing Python systems to existing .NET systems and that makes a lot of sense (you'd rather avoid rewriting chunks of either if you can and Ironclad acts as a bridge).
Hm. In the Java world, there are many target environments where depending on C extensions would not fly at all, since the only commonality between platforms is the JVM interface. (And sometimes not even that -- e.g. Android uses a different VM to run Java.) I'm guessing that in the .NET world this is much less of an issue, since (a) the platform is more homogeneous and under control of Microsoft (Mono notwithstanding) and (b) .NET explicitly targets other languages (though it prefers "managed C++", it supports plain C++). Have I got this right? I see the prospects for an IronClad-like thing in the Java world as pretty slim because of this.
Hehe, you actually raise several points in that short email. I'll address them one by one and try not to ramble too much.
Firstly, although you are correct that .NET supports a managed variant of C++ (that runs 'on .NET') and it is the same set of tools that you also use to compile native code (unmanaged C/C++) this has nothing to do with .NET. Python for Windows is compiled with the Visual C++ compiler but it doesn't run on .NET. .NET doesn't even use the MSVCRT that compiled native code links against - something that causes Ironclad 'difficulties' when managed and native code need to share file handles.
Ironclad itself has binary compatibility with Python C extensions, they don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with these extensions and on the JVM would use its FFI.
My understanding is that Android now allows native code, so if Dalvik has the same FFI APIs and you can compile the Python extensions for it *and* Jython runs on Dalvik (not currently the case I believe?) then it could work...
No need. Java has the Java Native Interface, which is supported in the Android Native Development Kit. Geremy Condra