ctypes - unloading implicitly loaded dlls

2008-07-27 Thread Scott Pigman
Here's what I'm struggling with (as best as I can understand it): I'm writing a program that uses functionality from two different sets of cdlls which reside in two different directories, call them 'libA.dll' and 'libB.dll'. Although I don't directly use it, both directories contain a dll with th

Can multiprocessing.Process() use a different version of the interpreter?

2010-10-04 Thread Scott Pigman
I want to use the 64 bit version of python but run some code inside a spawned process that uses the 32 bit version. Is there an official way to do this, or can anybody make a recommendation about the cleanest way to do this? If someone has a better solution to the problem I describe below, I'd app

Re: Can multiprocessing.Process() use a different version of the interpreter?

2010-10-04 Thread Scott Pigman
On Oct 4, 1:34 pm, Robert Kern wrote: > My previous statement notwithstanding, there is a way to hack this. The > windows-specific implementation of the class multiprocessing.forking.Popen > uses > a global variable, _python_exe, to determine the executable to use. Instead, > you What I've bee

Re: Can multiprocessing.Process() use a different version of the interpreter?

2010-10-04 Thread Scott Pigman
On Oct 4, 1:41 pm, Scott Pigman wrote: > _python.exe variable is built from sys.exec_prefix.  So, I think that sorry, _python_exe. -- http://mail.python.org/mailman/listinfo/python-list

Re: Can multiprocessing.Process() use a different version of the interpreter?

2010-10-04 Thread Scott Pigman
> > Personally, I think that subclassing is cleaner, but if you must monkeypatch, > then you should monkeypatch the multiprocessing.forking._python_exe variable, > not sys.exec_prefix. > > -- > Robert Kern thanks, good point. -- http://mail.python.org/mailman/listinfo/python-list