[Python-Dev] deprecate commands.getstatus() (original) (raw)

glyph at divmod.com glyph at divmod.com
Fri Mar 23 03:36:39 CET 2007

On 22 Mar, 09:37 pm, martin at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20070323/f492cea7/attachment.html

More information about the Python-Dev mailing list