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...

The .NET framework, even leaving aside Mono, is also diverse. There are several versions of the .NET framework: .NET CE (Compact Edition) that runs on mobile devices and the XBox 360, CoreCLR that runs on Silverlight and an embedded version. There is also a Mono application called MonoTouch that compiles .NET code for the iPhone (using Ahead Of Time compilation to generate native code).

The embedded version will never support IronPython. The compact edition of .NET currently lacks the System.Reflection.Emit (code generation APIs) that IronPython uses. You aren't supposed to use interpreters on the iPhone so likewise System.Reflection.Emit can't be compiled with MonoTouch. I mention them because the Microsoft dynamic languages team are looking at a cut down version of IronPython (with some of the more dynamic features restricted) that can run on .NET CE and could be compiled with MonoTouch. It is possible that Ironclad could work with this.

The CoreCLR in Silverlight does run IronPython but because of the sandboxing you can't call into native code, so you can't use Ironclad in the browser.

Despite the places where Ironclad doesn't work, *most* .NET code runs on desktops or servers using the standard .NET framework - and this is where Ironclad is used. Despite the variety of different JVMs this is an analogous situation and I don't see why a port wouldn't be just as useful.

As for Mono; Ironclad *currently* only works on .NET and on Windows. This is because it was originally created by Resolver Systems who only develop for Windows. There was *some* work by Seo Sanghyeon to port Ironclad to Mono, and there is nothing about the techniques Ironclad uses that would prevent it working on Mono. (Seo got distracted and the work was uncompleted but we're looking for volunteers to pick up porting Ironclad to Mono.)

All the best,

Michael Foord

> Michael

>> > [1] http://code.google.com/p/ironclad/

--
--Guido van Rossum

PS. My elbow needs a couple more weeks of rest. Limiting myself to
ultra-short emails.