2.6, 3.0, and truly independent intepreters

[Andy O'Meara]

> 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