lib.Result: Initialize with status = None #15
1 commit
| Author | SHA1 | Date | |
|---|---|---|---|
a739eb0763
|
jan/feature/20260615-lib-result-initialize-with-status-none into master | Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
a739eb0763
|
lib.Result: Initialize with status = None
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 3m9s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 3m4s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m3s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m10s
CI / Packaging test (push) Successful in 0s
Define default parameter values for Result's constructor, namely None for exit status, stdout and stderr. Instantiating a Result object without parameters signifies "this object doesn't contain data from a real process's exit event". Up to now, similar meaning has been hand-crafted by ExecContext's run() and friends by using an error exit status (1) to make sure it wasn't mistaken for success. This commit formalizes that into the Result structure itself, but uses None instead for the exit status. Controlling default values in Result itself also means that the Result class gets better awareness of what it contains, and its log messages and stdin / stdout can be more fitting: - If a real process failed, make stdout return at least b'' - If a real process succeeded, make stdout return at least b'' Returning something from .stdout on success fixes a real bug: An attempt to access what "rpm -U somepackage.rpm" returns, namely nothing, raises a bogus exception, because stdout is None. Signed-off-by: Jan Lindemann <jan@janware.com> |