Calling Python from C# - please help

Samuele Pedroni pedronis at
Wed Sep 18 03:19:23 EDT 2002

Mark Hammond <mhammond at> wrote in message
IpSh9.17251$Ee4.52376 at
> 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
> > 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 also the workaround MS proposes to the people that encounter the

> > that's OK for static languages, or environments with a clear run/design
> > 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
> > speed for a enviroment that allows for redefinitions and eval, ...
> >
> > In Jython we create Java bytecode and dynamically load classes for all
> > 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
> > for exec and eval support, and that seems what JScript does for jsc
> > code containing eval, that means the script is compiled but the
> > 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.

Indeed, that's also what they allow for their regex impl, but if one reads
the fine points about regex

"However, generated MSIL cannot be unloaded. The only way to unload code is
to unload an entire application domain ..."
... Out of mem danger.

> > otherwise a long running process using eval could go out of memory.
> >
> > That's something people wanting to write a feature complete impl of
> > 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.

but that means Remoting ...

>  Managing
> the lifetime of the dynamically created domains may be an issue though.

I fear yes, also given that the reload unit of Python is a module, one would
need one AppDomain for each module,exec unit
etc produced code and then a way to manage the lifetime of all this
distributed-across-AppDoms stuff.
A lot of headaches for what externally seems just a very shortsighted design
decision on their part.

Otherwise, as I said, there's the interpreter route, which is JScript eval


More information about the Python-list mailing list