Calling Python from C# - please help

[Samuele Pedroni]

Mark Hammond <mhammond at skippinet.com.au> wrote in message
IpSh9.17251$Ee4.52376 at news-server.bigpond.net.au...
> 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 also the workaround MS proposes to the people that encounter the
issue.
But

> > 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.

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconcompilationreuse.asp

"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
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.

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
approach...

regards.