-
由 Cleber Rosa 提交于
This brings a change in behaviour, in which the stdout/stderr of the executed process will now be of bytes type, instead of a string type. Two new attributes, which are implemented as properties, have been added to the CmdResult class, `stdout_text` and `stderr_text`. Those are convenience methods that will return the same content that is in `stdout` and `stderr`, reespectively, but decoded on the fly[1]. With regards to encoding, if one is not provided, the result of `sys.getdefaultencoding()` will be used ("utf-8" for Python 3 and "ascii" for Python 2). Applications and/or tests using the APIs that return a CmdResult should, to the best of my knowledge, set a default encoding themselves so a stable behavior across Python versions. But that if left to users of this API. A different tradeoff/design decision has to do with the tests modified here. One option is to have "text" (as in sequences of human readable glyphs) as being of Python type "str". On Python 2, "str" can be compared to "bytes" because a conversion will happen on demand. That is, the following is fine on Python 2: >>> result = process.run("command") >>> "expected" in process.stdout Where `expected` is of type "str" and `process.stdout` is of type "bytes". This is not true of Python 3, so either the types must match or a conversion must be done explicitly. The solutions to that are: 1) have these "text" as (of type) "bytes" in the source code itself, and avoid the conversion whenever possible 2) have "strings" in the source code itself, and use the conversion provided by `CmdResult.stdout_text` and `CmdResult.stderr_text`. The approach chosen here is to avoid conversion if possible, that is, use "byte" types, given the fact that the source code encoding is by default 'ascii' and most of the "text" dealt with here can be represented in 'ascii' too. This is equivalent of doing: result = process.run("command") b"expected" in process.stdout "errors: %s" % 0 in process.stderr_text [1] The obvious alternative, instead of decoding these on the fly would be to have multiple copies of the "same" data. This assumes that binary data produced on the stdout/stderr will usually be larger than textual data. Signed-off-by: NCleber Rosa <crosa@redhat.com>
7d0e6a44