[IronPython] PyPy meets Jython (could meet IronPython too?)

[Michael Foord]

Antonio Cuni wrote:
> Michael Foord wrote:
>
>> It would be great to see IronPython participate. A common set of 
>> language tests, written in pure Python, could greatly benefit 
>> IronPython.
>
> I (we) agree.  Right now we have python compliance tests scattered all 
> over the places: there are cpython's regression tests, and both pypy 
> and jython has their own additional tests.  I bet IronPython is not 
> different here.
>
> It would be great to have a set of tests that defines what you can 
> expect to be guaranteed from a python implementation, shared among all 
> the various projects.  Unfortunately I think we are all busy with 
> other things/priorities, so I don't expect this to happen very soon.
>

It would be great to see this as a separate project (pyspec?) so that 
CPython, IronPython, PyPy and Jython developers can work on it.

Of course for maximum platform compatibility it should be based on 
unittest...

:-)

Of course internal 'legal issues' may make it hard for the IronPython 
team to be involved. Hopefully this a hurdle that could be overcome.

Making it a separate project may make it harder to get core developers 
from the platform implementation excited about it - but it is hard to 
see how any combined effort can be made otherwise. This is one area the 
Ruby community leads the Python community.

>> Additionally, an implementation of ctypes for IronPython (using the 
>> .NET FFI and building on the PyPy work) would enable IronPython to 
>> use any of the extension modules developed for Python by PyPy. More 
>> and more standard library modules are implemented using ctypes now.
>
> well, hopefully it would also enable pypy to run extension modules 
> implemented by others; don't let us doing all the boring work :-).

:-)
>
> Apart from jokes, I think that it should be very easy to port ctypes 
> to ironpython that way: pypy's ctypes implementation is mostly written 
> in pure python as a wrapper around a tiny library called _rawffi, 
> which enables very low level interaction with external C libraries; 
> so, it's enough to implement _rawffi for IronPython and everything 
> should just work.
>
> And hopefully, we could even backport that _rawffi to pypy to have a 
> working ctypes for pypy-cli for free :-) (modulo license issues, which 
> in an ideal world would not be a blocker, but you never know).

Both of these would be great - and the Microsoft license is very permissive.

It would probably be more of a problem for *them* to depend on the PyPy 
ctypes implementation though. :-(

Personally I think that a Python 2.5 implementation (IronPython 2) is 
incomplete without ctypes of course...

Incidentally, it would probably be possible to implement _rawffi for 
IronPython in pure Python - building on the dynamic platform invoke work 
that Seo started for ctypes.

Michael Foord

>
> ciao,
> Anto
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/