The solution about providing faked python24.dll could be pushed a little bit further. Why not provide "a reasonable subset" of python24.dll (and Python.h) as calls to .NET objects representing IronPython stuff. This would not work if those objects are treated by hand (by accessing they're fields), but IMHO it barely happens. Usually all manipulations are done via macro calls, which wouldn't be macros in this case. This would invalidate hell-a-lot of problems, including keeping copies of everything all over the place. There are surely some limitations (macros are faster ie), but sounds like solution which can be pushed a bit further.

Cheers,
fijal
fijal | 07/11/06 - 3:47 pm | #