On 07/25/2010 02:46 PM, Edward Diener wrote: > The problem with this is that you forget that a script can invoke Python > internally. So whether one uses the console or file association method > of invoking Python externally, any already written script can use either > internally.
Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. If you let .py scripts specify which interpreter they'd like to be run with in the first line, with some sort of pystarter script that you map to the file extensions (or by using UNIX), this should work equally well no matter if the script being run by a script or by a user. If you invoke the Python interpreter directly, you should NEVER EVER assume that the interpreter is in a certain place, or on the PATH. It's a stupid idea: what if it's not? Instead, if you really must, invoke sys.executable instead of guessing. Obviously, Windows doesn't have fork(), but still, I don't see any reason to leave the comfort of your own running interpreter: you can use runpy to run python scripts. If you want them to run in the background, you can use threads, or, if you require (or want) separate processes, use multiprocessing. -- http://mail.python.org/mailman/listinfo/python-list
