[IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Michael Foord]

Matt Clinton wrote:
>
> NumPy is largely about speed, and going through extra interop layers 
> can really bite into that (my $0.02).
>

The reason that Numpy is much faster is because most of the work happens 
inside the C code, so a minor performance hit on the way in and out 
isn't necessarily a problem.

> I think the suggestion for a smaller module to start with was about 
> learning about compatibility with a more manageable chunk of code than 
> the many, many lines of deep number-crunching that NumPy has 
> accumulated, but maybe a few sections of compatibility there (i.e. 
> limited part of the API) would be a similarly tractable goal?
>
Possibly.
>
> Wrapping the plain-C in COM would be a good way to test implementation 
> compatibility,
>
I'm not sure that COM is the way to go (because it does seem to insert 
an extra layer into the equation) - but it is certainly on the table.

> if your plan is to ported raw C to C++,
>
That wasn't at all the *original* plan. :-)

> so that the DLR/CLR can get some hooks in and go-quicka:
>
> the COM-wrapped CPy extensions may be faster to develop, if not 
> performing as quickly,
>
> and if your C++ ports behave the same, you have pretty good confidence.
>
> Along the way, they’ll help point out what’s the framework and what’s 
> your code, especially if you can run the same test-cases through 
> straight CPy.
>
> Wrapping all the way back through Mono seems an odd goal – isn’t IPy 
> compatible enough with CPy in source that your business apps would be 
> light to port back to Cpy-land, if you’re on Posix already anyway?
>

No - our application is currently a .NET only (not Mono) application, 
with a heavy dependency on .NET for the user interface layer. So back 
porting the whole app. to CPython is not on the cards (for business 
reasons as well - getting the finance sector to install new technology 
is difficult, so a .NET based application will more easily be accepted 
by companies than a CPython one).

> For some purposes, it really makes sense, but a NumPy implementation 
> for IPy for Mono?
>
We are not talking particularly about a new implementation, but finding 
a way of getting the current implementation to work.

> Seem to me that going that deep this soon will make you a valuable 
> contributor to low-level compatibility testing… but I don’t have the 
> whole picture of where you’re going.
>
> If you’re going to alloy FePy, would that make a type of SteelPython? 
> – a happier compound than Rust!
>
RustPython is one of the possible names (what happens when you introduce 
Iron to the Sea... Moray would be another one - a kind of Python that 
lives in the sea... better names solicited...) :-)

Michael
http://www.manning.com/foord

> Cheers,
>
> -- Matt
>
> ------------------------------------------------------------------------
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Giles Thomas
> *Sent:* Monday, October 15, 2007 9:17 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Announcement: Project to get some CPython 
> C extensions running under IronPython
>
> Davy,
>
> What would the issues be with NumPy - just the size of the API that 
> would have to be wrapped? I must admin that my biggest concern with 
> this would be getting everything running under Mono...
>
>
> Cheers,
>
> Giles
>
>
> Davy Mitchell wrote:
>
> On 10/12/07, Giles Thomas <giles.thomas at resolversystems.com> <mailto:giles.thomas at resolversystems.com> wrote:
>   
>> Python and .NET, but also the existing CPython C extensions.
>>     
>  
> Hi Giles,
>  
> Sounds like a good idea and the approaches mentioned seemed solid.
>  
> One strategy I was considering for a port of my Mood News site to
> Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM
> object using the win32 stuff and getting it into .Net via the COM
> interop support.
>  
> Maybe not practical for Numpy :-) Does have the advantage of not
> having to modify the original lib...
>  
> Cheers,
> Davy
>  
>   
>
>
>
> -- 
> Giles Thomas
> MD & CTO, Resolver Systems Ltd.
> giles.thomas at resolversystems.com <mailto:giles.thomas at resolversystems.com>
> +44 (0) 20 7253 6372
>  
> We're hiring! http://www.resolversystems.com/jobs/ 
>  
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79 
> Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>