Re: [IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython)
Was an answer to this ever given? At 12:34 PM 9/1/2006, Jason Ferrara wrote >If I wanted to write a stub in C#, how do I get access to a >PythonEngine that represents the python environment that called the >C# code? Just calling IronPython.Hosting.PythonEngine() seems to get >me a new environment. J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython)
Not that I saw. On Sep 18, 2006, at 11:14 AM, J. Merrill wrote: > Was an answer to this ever given? > > At 12:34 PM 9/1/2006, Jason Ferrara wrote >> If I wanted to write a stub in C#, how do I get access to a >> PythonEngine that represents the python environment that called the >> C# code? Just calling IronPython.Hosting.PythonEngine() seems to get >> me a new environment. > > > J. Merrill / Analytical Software Corp > > > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython)
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 :) ). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ferrara Sent: Monday, September 18, 2006 8:48 AM To: Discussion of IronPython Subject: Re: [IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython) Not that I saw. On Sep 18, 2006, at 11:14 AM, J. Merrill wrote: > Was an answer to this ever given? > > At 12:34 PM 9/1/2006, Jason Ferrara wrote >> If I wanted to write a stub in C#, how do I get access to a >> PythonEngine that represents the python environment that called the >> C# code? Just calling IronPython.Hosting.PythonEngine() seems to get >> me a new environment. > > > J. Merrill / Analytical Software Corp > > > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython)
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 :) ). > ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython)
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 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
