Calling Python from C# - please help

Mark Hammond mhammond at skippinet.com.au
Wed Sep 18 05:28:40 CEST 2002


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.




More information about the Python-list mailing list