[Python-ideas] stdlib with its own release cycle ?

[Michael Foord]

2009/10/26 Guido van Rossum <guido at python.org>

> On Sun, Oct 25, 2009 at 5:12 PM, Michael Foord <fuzzyman at gmail.com> wrote:
> >
> >
> > 2009/10/25 Guido van Rossum <guido at python.org>
> >>
> >> On Sun, Oct 25, 2009 at 4:38 PM, Michael Foord <fuzzyman at 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.
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20091026/87f47391/attachment.html>