2.6, 3.0, and truly independent intepreters
Andy O'Meara
andy55 at gmail.com
Fri Oct 24 10:58:52 EDT 2008
> That aside, the fundamental problem is what I perceive a fundamental
> design flaw in Python's C API. In Java JNI, each function takes a
> JNIEnv* pointer as their first argument. There is nothing the
> prevents you from embedding several JVMs in a process. Python can
> create embedded subinterpreters, but it works differently. It swaps
> subinterpreters like a finite state machine: only one is concurrently
> active, and the GIL is shared.
Bingo, it seems that you've hit it right on the head there. Sadly,
that's why I regard this thread largely futile (but I'm an optimist
when it comes to cool software communities so here I am). I've been
afraid to say it for fear of getting mauled by everyone here, but I
would definitely agree if there was a context (i.e. environment)
object passed around then perhaps we'd have the best of all worlds.
*winces*
>
> > This is discussed earlier in the thread--they're unfortunately all
> > out.
>
> It occurs to me that tcl is doing what you want. Have you ever thought
> of not using Python?
Bingo again. Our research says that the options are tcl, perl
(although it's generally untested and not recommended by the
community--definitely dealbreakers for a commercial user like us), and
lua. Also, I'd rather saw off my own right arm than adopt perl, so
that's out. :^)
As I mentioned, we're looking to either (1) support a python dev
community effort, (2) make our own high-performance python interpreter
(that uses an env object as you described), or (3) drop python and go
to lua. I'm favoring them in the order I list them, but the more I
discuss the issue with folks here, the more people seem to be
unfortunately very divided on (1).
Andy
More information about the Python-list
mailing list