[C++-sig] Re: Presenting a Python embedding tutorial for Boost.Python

[Dirk Gerrits]

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
>>this point.
> 
> 
> 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?
> 
> Thanks,
> Dave
> 
http://www.modpython.org/live/mod_python-2.7/doc/pyapi-interps.html: 
(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 
just fine.

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.

- Dirk