[IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython)

[J. Merrill]

Can you use the .Net stack trace mechanisms to "look back up the call stack"?  I would think that you could, but I don't know how you'd necessarily get the value of the PythonEngine that you find.

Could you have a "static constructor" in your C# assemblies that does the right thing?  Such code is called "at most once" which sounds like what you need.

At 12:44 PM 9/20/2006, Jason Ferrara wrote
>In my case I'm looking to write assemblies in C# that makes use of  
>modules defined in IronPython that others can use without having to  
>know or care that they use IronPython (except for having to have the  
>IronPython dlls around). Things are complicated by the fact that some  
>of the modules used need to have a single global environment. If C#  
>assemblies A and B both use IronPython assembly C, A and B need to  
>use the same PythonEngine or things won't work right. And if A and B  
>are being used from IronPython, then they need to use the  
>PythonEngine of the caller.
>
>So I guess I need some sort of magic that when a call is made into  
>the assembly it looks back up the call stack to see if there is a  
>PythonEngine, and if so uses that one. If not create its own and then  
>keep that one around for the next time the assembly is entered  
>without a PythonEngine in the call stack.
>
>
>On Sep 18, 2006, at 12:11 PM, Dino Viehland wrote:
>
>> Probably the lack of an answer is due to the fact that there isn't  
>> a really great way to do this.  Here's two possible ways to pull  
>> this off:
>>
>> For #1 you presumably kicked off the Python code via the hosting  
>> APIs, and therefore you know the engine that kicked it off.  If you  
>> have multiple Python engines this might be tricky (if you have only  
>> one running on each thread at a time you could store it in a  
>> [ThreadStatic]).  If you start getting into more complicated  
>> scenarios obviously this is going to break down quickly...
>>
>> For #2 you're looking at using ICallerContext.  This is a bit of  
>> internal machinery that IronPython uses to flow state around for  
>> things that might need state (e.g. hiding CLR methods, locals(),  
>> exec, etc...).  Off of ICallerContext there is both a SystemState  
>> and a PythonModule property.  Unfortunately there's nothing that  
>> leads you directly to a PythonEngine.  Instead you'd need to  
>> maintain a table of either modules->engines or SystemState (sys  
>> module) -> engines.
>>
>> #2 will work reliably if you control the creation of all engines in  
>> the process - the instance you go out of that it'll break down.   
>> The alternate plan here might be that having access to a  
>> SystemState and PythonModule you could already do some interesting  
>> things even though you don't have the full blown PythonEngine.   
>> It'd be interesting to hear if those are sufficient or if you  
>> really do need the engine in this case (and how horrible you think  
>> the 2 solutions are :) ).


J. Merrill / Analytical Software Corp