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
[email protected]
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/
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
