2008/5/30 Farshid Lashkari firstname.lastname@example.org:
I'm not sure if there will be any side affects to modifying sys.executable though. Should this be the official way of supporting embedded interpreters or should there be a multiprocessing.setExecutable() method?
+1 for setExecutable (I'd prefer set_executable, to be PEP 8 compliant). Make it explicit, rather than fiddling with stuff in sys manually.
sys.executable typically means the "current" executable, and py2exe etc already fiddles with that. The question in such a context seems to be "what executable should I use for this processing functionality?". In a py2exe like environment, it might not be unreasonable to assume that if a custom executable is to be used, that custom executable may have a different command-line or other special requirements. Further, I could imagine a system that uses an alternative way of starting processes (eg, 'distributed COM') where the concept of 'executable' (or even 'command-line') don't make much sense.
So it seems that maybe simply "setExecutable()" isn't the correct abstraction here, but maybe a "factory" approach, so the entire process creation mechanism can be replaced rather than just the name of the executable to spawn?