<html><body><br />On 22 Mar, 09:37 pm, martin@v.loewis.de wrote:<br />>> Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),<br />>> that abomination invented by Microsoft?<br />><br />>Right, I personally would not miss it. It's also not a system call,<br />>but a library function on both Windows and Unix (the equivalent<br />>of exposing fork would be to expose CreateProcessEx - something<br />>that I think Python should do out of the box, and not just when<br />>PythonWin is installed - but you can now get it through ctypes).<br /><br />>> I also hear no opposition<br />>> against killign os.system() and os.popen().<br />><br />>Both are library functions; I can implement them in Python on top<br />>of what is there (plus popen is based on stdio, which we declared<br />>evil). So yes, the can go.<br /><br />In the long term (read: 3k) I think I agree completely.<br /><br />It seems that this is a clear-cut case of TATMWTDI ("there are too many ways to do it") and the subprocess module should satisfy all of these use-cases.<br /><br />I also like Martin's earlier suggestion of calling the remaining OS process-manipulation functions "posix.fork", etc.  I think it would be a lot clearer to read and maintain the implementation of subprocess (and asynchronous equivalents, like Twisted's process support) if the platform back-ends were explicitly using APIs in platform-specific modules.  The current Twisted implementation misleadingly looks like the UNIX implementation is cross-platform because it uses functions in the "os" module, whereas the Windows implementation uses win32all.<br /><br /></body></html>