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

[geremy condra]

On Mon, Oct 26, 2009 at 5:47 AM, Michael Foord <fuzzyman at gmail.com> wrote:
>
>
> 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...
>

No need. Java has the Java Native Interface, which is supported in the
Android Native Development Kit.

Geremy Condra