[C++-sig] Re: Presenting a Python embedding tutorial for Boost.Python
dirk at gerrits.homeip.net
Wed Dec 11 17:13:09 CET 2002
David Abrahams wrote:
> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>>Mike Rovner wrote:
>>>"Dirk Gerrits" <dirk at gerrits.homeip.net> wrote in message
>>>news:at59bp$skj$1 at main.gmane.org...
>>>>Furthermore, there should be a way to set/query the currently active
>>>>interpreter. Member functions like this:
>>>> bool is_current() const;
>>>> void make_current();
>>>>were the first things that came to mind.
>>>How about being consistent with scope() interface?
>>>Creating new interpreter changes current, but one can create
>>>objects to keep and use another.
>>>Just my 2c.
>>I like the idea of making the new instance the current interpeter. I'm
>>just not so sure what the destructor of the current interpreter should
>>do. Perhaps the most current interpreter still in scope should be
>>looked up in an interpreter registry? Or would it make sense to have
>>no current interpreter at all?
>>I just don't know enough about creating and using sub-interpreters at
> I'd like to help make this decision, but I'm having trouble imagining
> what the consequences or usefulness of having multiple interpreters
> is. I didn't read that whole article I pointed you at ;-/. Can you
> give me the quick skinny on this?
(near the top)
"Subinterpreters are very useful to make sure that separate programs
running under the same Apache server do not interfere with one another."
http://www.mcmillan-inc.com/embed2.html (near the bottom) says that you
need to have multiple interpreters if you are calling Python from
multiple threads and those threads were not created by Python. (Ie Win32
threads, Boost threads, etc.)
And perhaps there are more reasons that I missed?
Neither of these applies to me at the moment though. And I don't think
they will in the (near) future. For me, a python::interpreter which can
only have one instance which represents the main interpreter would be
I have however read one message (not on this list) of someone who
switched to Lua exactly for the reason that making multiple non-Python
threads work with Python was so hard and error-prone.
I don't feel I can decide on the matter of supporting multiple
interpreters or not. Either would suit me.
More information about the Cplusplus-sig