Tighter Win32 Integration with IronPython for Mono/.NET

[jamesm@…]

I saw this recently and thought it was interesting…

​http://www.ironpython.com/

Its a Python interpreter for Mono/.NET. It may be possible to package Tracd (for example) to run on the CLR. This would be nice because it may simplify installation and may reduce the number of dependencies.

[Jonas Borgström]

What kind of win32 integration would you like to see?

Making Trac run on IronPython will probably require much much more work than simply making Trac easier to install on win32 platforms. IronPython currently doesn't even support standard python library modules like, os or StringIO.

[jamesm@…]

Actually, I'm quite happy with the way things are now. I just thought I'd bring it to the team's attention to see if it may be useful. If IronPython offers nothing new/interesting then no big deal.

[mladen@…]

I'd also be interested to see how Trac run on this. They are claiming that it is at least twice as fast as normal python (see ​http://www.sdtimes.com/article/story-20060201-04.html). That alone could be a great feature.

Couldn't the standard python libraries just be made to run on IronPython too?

If anyone has played with this maybe you could share your experiences? If someone wants to write a little document on how to run Trac using IronPython that would also be cool as I don't really know python too well so I'm not sure where to start myself.

[Matthew Good]

Trac relies on CPython natively compiled modules for the ClearSilver and SVN libraries which prevents IronPython compatibility.

[anonymous]

But if those libraries could run on ironpython, would that be a good start? Would you condider changing trac in order for it to be able to run on the .net framework?

[Matthew Good]

Replying to anonymous:

But if those libraries could run on ironpython, would that be a good start? Would you condider changing trac in order for it to be able to run on the .net framework?

It's already possible to disable the SVN portions of Trac. In 0.11 ClearSilver will no longer be a dependency. It's replacement, ​Markup, depends on Python bytecode generation, which I don't know if IronPython supports. Trac also requires a database library, all of which currently depend on CPython.

IronPython does not provide the "md5" module which is used by Trac. It also doesn't have "zipimport" which means that you can't use zipped plugins.

So at this point it looks like there are still a number of things IronPython will need to implement before it will be possible to consider making Trac compatible with it.

[davidf@…]

I don't think Markup (now Genshi) does Python bytecode generation - is there a reference to that? There are some replacement modules that I have found useful in trying to port our web framework to Python by Seo Sanghyeon - including md5, socket, pyexpat and he's even working on a dbapi using ADO.NET

[Christopher Lenz]

Replying to davidf@sjsoft.com:

I don't think Markup (now Genshi) does Python bytecode generation - is there a reference to that?

Sure, see the genshi.eval module:

​http://genshi.edgewall.org/browser/trunk/genshi/eval.py?rev=299#L154

In particular, the bytecode generation depends on the compiler module. I have no idea if that (or something equivalent) is available for IronPython.

[Matthew Good]

Replying to cmlenz:

In particular, the bytecode generation depends on the compiler module. I have no idea if that (or something equivalent) is available for IronPython.

No, IronPython does not provide this module. Users interested in Python on the CLR should also look into PyPy, which is a project focused on making Python easily translatable to many runtime environments.

[sanxiyn@…]

Re: jonas IronPython supports os and StringIO module now.

Re: mgood As you pointed out, ClearSilver is a C extension and can't be made to run on IronPython. I think getting Genshi run would be possible though. See below.

For SVN access, I am willing to write a VC plugin using .NET subversion libraries like NSvn.

For a database library, I have DB-API implementation backed by ADO.NET and a compatibility module for sqlite ready.

I also have md5 module using System.Security.Cryptograpy ready.

For compiler package, the package itself is pure-Python, the problem lies on parser module. PyPy project wrote a pure-Python implementation of parser module, which should run just fine on IronPython: ​http://codespeak.net/svn/pypy/dist/pypy/interpreter/pyparser/

Another possibility is new _ast interface in Python 2.5. (See ​http://genshi.edgewall.org/changeset/31) Unlike old parser interface, it looks very feasible for IronPython to implement this interface.

Bytecode generation is problematic. Naturally IronPython can't support new.code called with CPython bytecode. I am thinking about using unparse to turn that to Python source and then exec to get a code object: ​http://svn.python.org/projects/python/branches/p3yk/Demo/parser/unparse.py

Lots of rough ideas.

[Matthew Good]

Replying to sanxiyn@gmail.com:

Another possibility is new _ast interface in Python 2.5. (See ​http://genshi.edgewall.org/changeset/31) Unlike old parser interface, it looks very feasible for IronPython to implement this interface.

Actually Genshi no longer uses the _ast package, but instead uses compiler.ast and compiler.pycodegen for transforming the parsed code into bytecode (both are written in Python).

Bytecode generation is problematic. Naturally IronPython can't support new.code called with CPython bytecode. I am thinking about using unparse to turn that to Python source and then exec to get a code object: ​http://svn.python.org/projects/python/branches/p3yk/Demo/parser/unparse.py

I guess you could also look at the compiler.pycodegen package to see if it could be rewritten for generating IronPython code objects.

[anonymous]

I would suggest all ideas, suggestions, code, etc should be posted on the IronPython mailing list. The guys were a bit optimistic and there were already some good suggestions on the list. If we group all efforts together perhaps it can be done faster:

[anonymous]

I too would like to see this implemented. It would mean Trac could be deployed within companies that want to standardise on the .net platform.

[Mika]

I'd also love to see this.

Also check out ​http://fepy.sourceforge.net/

[marcus]

+1 vote for reopening this ticket

[djanosik]

What about now? Is it possible?