Anyone have any good/bad experiences integrating Python .NET into their scripting engine? I'm developing a project using C#, and I've decided to use Python for my scripting engine. All I need is to make some calls from the Python API. I could either [DLLImport] the functions that I need from the Python C API, or go with Python .NET. However, I don't need the overhead of having the .NET Framework exposed to my Python scripts. I'm worried about the efficiency of Python .NET as well. IronPython looks promising as a first-class .NET language, but unfortunately it's not publicly released yet. Any input? Cheers, Estese

Python.NET was an experiment, not really suitable for public consumption (I have not tried it, it's just the feeling I got from the talks at PyCon 2004). Efficiency was indeed a major issue. If I were you, I would wait for IronPython to be available.

Actually, there are two projects I know of that call themselves Python .NET, ActiveState's and Zope's. The Zope Python .NET project is focused on porting the runtime to .NET and the ActiveState project is (was?) focused on making Python a true .NET language. Which one are you refering to?

The ActiveState one.

SiCrane: I was referring to the Zope implementation. I just glanced at the ActiveState implementation, and it looks promising. Unfortunately, the link to the Python .NET whitepaper isn't working. I'll look into it a bit more.

Fruny: There is no scheduled release date for IronPython, so for all we know, it could be 6 months on the horizon.

In summary, using Python with .NET is currently not production-ready. I've tried the Zope "Python for .NET" implementation and it works, but it's... not quite ready for primetime.

I'd wait for IronPython, too.

Oluseyi: Would you mind elaborating a bit on your experiences with the Zope implementation? Did you do any profiling to measure performance? Did you embed it in a .NET project, or use it standalone?

The Zope project merely allows you to consume .NET assemblies from Python - ie, you can use .NET types from inside Python. It does not allow you to implement .NET types in Python itself.

IronPython looks very promising, since it seems to be both a full CLR consumer and a CLR producer, but it remains to be seen when it will ever see the light of day.