[IronPython] PyPy meets Jython (could meet IronPython too?)
fuzzyman at voidspace.org.uk
Thu Jul 10 14:39:44 CEST 2008
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
> 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
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.
> Users mailing list
> Users at lists.ironpython.com
More information about the Ironpython-users