> 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 -- http://mail.python.org/mailman/listinfo/python-list
