[Python-Dev] deprecate commands.getstatus()
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