RetroSearch Browse

Fri Mar 23 03:36:39 CET 2007 · https://mail.python.org/pipermail/python-dev/2007-March/072300.html

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 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-March/072300.html below:

[Python-Dev] deprecate commands.getstatus()