Calling Python from C# - please help

[Mark Hammond]

Samuele Pedroni wrote:

> How were you going to support eval and exec?

The compiler itself is written in CPython.  The intention was to get the 
compiler good enough to compile itself - then we will have a .NET 
compiler able to be built into the Python runtime.  exec and eval would 
leverage this.

> For the moment the unload granularity of .NET is AppDomains only and only
> upon explicit request, and types/modules/assemblies are not garbage
> collected but simply live as much as the AppDomain,

App Domains can be dynamically created tho, which may help.

> that's OK for static languages, or environments with a clear run/design time
> distinction (one can setup an AppDomain and tear it down for each
> run-cycle), or for running scripts in isolation but not if one wants IL/JIT
> speed for a enviroment that allows for redefinitions and eval, ...
> 
> In Jython we create Java bytecode and dynamically load classes for all the
> code, also eval code because in Java classes are elegible for garbage
> collection.
> 
> In .NET it seems one needs a pure interpreter that does not compile to IL
> for exec and eval support, and that seems what JScript does for jsc compiled
> code containing eval, that means the script is compiled but the evaluated
> code is only interpreted,

Im not really convinced of that.  Reflection::Emit has IL generation 
capabilities purely for "dynamic" code - the example used in their docs 
is that regex engines could compile down to IL on-the-fly.

> otherwise a long running process using eval could go out of memory.
> 
> That's something people wanting to write a feature complete impl of Pyhton
> for .NET should consider or wait MS to implement a more
> dynamic-environment-friendly unload policy.

Yes, I see your point, but AppDomains are really quite powerful.  I 
believe there are no restrictions between cross domain calls.  Managing 
the lifetime of the dynamically created domains may be an issue though.

Thanks for the comments,

Mark.