From: Peter Åstrand
>> - The poll() method and returncode attribute aren't both needed. I like
>> returncode's semantics better since it gives more information and it
>> avoids using -1 as a magic number.
> Well, as I described in another mail, it's actually a big advantage to
> provide both a returncode attribute and an unmodified status value, since
> it's makes it easy to migrate from the "old" API. Perhaps we'll need to
> make some changes to the poll() method wrt Windows, though.
The peculiar "combined" nature of a Unix status value has no analogue in
Windows. And in the context of an object with multiple attributes, I don't
see the need anyway. I'd suggest
Popen.returncode - Process return code, valid on both Unix and Windows
Popen.signal - Signal which caused the program to exit, Unix only.
Code which is meant to be portable (to whatever extent that is possible) can
use returncode without any problems. Code which is Unix-specific can worry
about signal. (I'd suggest signal=0 means no signal occurred, and on Windows,
signal is always 0. This means that it's still possible to write portable code
which tests signal.)
I'm not sure I see "migration from the old API" as an issue. Certainly not a
"big advantage". This module should attempt to be "the best possible design",
and as such should take the chance to ignore backwards compatibility. If it's
good enough, people will be glad to change code to match. If it's *not* good
enough, it won't succeed even if it tries to be compatible.
This applies both to compatibility with existing Python modules (popenXXX, os,
etc) and to compatibility with C APIs (which is where the overloaded returncode
comes from). Let's get a good Pythonic design.
Paul.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4