On 22 Mar, 09:37 pm, [EMAIL PROTECTED] 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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
