(original) (raw)

On 22 Mar, 09:37 pm, martin@v.loewis.de wrote:
>> Sure. os.fork() and the os.exec\*() family can stay. But os.spawn\*(),
>> that abomination invented by Microsoft?
>
>Right, I personally would not miss it. It's also not a system call,
>but a library function on both Windows and Unix (the equivalent
>of exposing fork would be to expose CreateProcessEx - something
>that I think Python should do out of the box, and not just when
>PythonWin is installed - but you can now get it through ctypes).

>> I also hear no opposition
>> against killign os.system() and os.popen().
>
>Both are library functions; I can implement them in Python on top
>of what is there (plus popen is based on stdio, which we declared
>evil). So yes, the can go.

In the long term (read: 3k) I think I agree completely.

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.

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.