Building an extension that calls the Python interpreter recursively.

[Martin v. Loewis]

"Parzival Herzog" <parz at shaw.SpamBucket.ca> writes:

> I would like to know if this scheme is feasible

Yes, it sounds good.

> 1) Can the Python interpreter be re-invoked from an
> extension module?

Yes; anything that you can write in Python can also be invoked as a
series of API calls. This particular API is PyRun_String.

> 2) Will it process its evaluation of S in the same
> interpreter context that originally invoked ML1.process?

Yes, unless you play with threads (and even then this is easily
achieved).

> I.e. will results left by PyRun_String be accessible
> after process() returns?

Depends on what "results" is. If you execute statements, side effects,
such as modifying globals or locals, or changing attributes of objects
reachable through globals or locals, will persist.

If the string you run is an expression, you need to worry about
returning the result.

> 3) Are there gotchas or constraints on the global
> interpreter lock that I should be aware of under these
> circumstances?

As long as you hold the lock, no other Python threads will run. So if
this is a long-running action, you should release the lock inside
.process(). Then, before calling into Python, you need to create a new
thread state, acquire the lock for this thread state, and call into
Python. As a result, tracebacks will "end" in the callback.

As an alternative, you might consider just to keep the interpreter
lock.

Regards,
Martin