On Thu, 6 Mar 2008, Bill Janssen wrote:
You can also get this env value by calling getVMEnv() as in:
>>> import foo
>>> foo.initVM(foo.CLASSPATH)
>>> import os, foo, bar
>>> bar.initVM(classpath=os.pathsep.join([foo.CLASSPATH, bar.CLASSPATH]),
env=foo.getVMEnv())
This is close, but what I'd really like to be able to do call
bar.getVMEnv() to get the environment. I don't have a handle on foo
at this point, and it would introduce a lot of coupling to keep one.
If the classpath resetting doesn't stick, try setting it to both in the
first initVM() call.
Nasty coupling effect. I don't want foo to have to know about bar,
and I don't want bar to have to know about foo.
Yes, I agree but the coupling is there anyway since there can be only one VM
running in your process. I don't have a process global variable in python to
stick the vm handle into. The next best thing is to ask the module you
'know' about.
Maybe I could stick the VM handle into a thread local variable on the main
thread ? If there is no value, it's a new VM, if there is one, you add to
it. The problem with that approach is that there are bunch of things about
the VM you can't change once it's started and so there is likely to be a
certain amount of coordination required between your modules so that they
can all share the VM. For example, max stack and heap sizes come to mind.
In other words, making this less coupled is a losing battle anyway.
(apart from maybe the classpath setting which could be changed to be
additive instead of replacing the current one). (this reminds me that I
don't know at this time how setting the classpath this way interacts with
the CLASSPATH env var, it's probably stomping on that too). (hence it's
probably best to explicitely set classpath in initVM() to everything you
want in it, at this time)
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
