> 2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>: > > 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? Cheers, Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
