On 4/27/18 5:28 PM, Tres Seaver wrote:
On 04/27/2018 05:11 PM, Tim Peters wrote:
In this specific case, line-oriented coverage tools have missed accounting for all possible code paths since day #1; e.g.,
x = f() or g()
You don't need to reply to messages so obviously irrelevant to the PEP unless you want to. It's not like Guido will read them and go "oh! a binding expression in a ternary conditional is a fundamentally new potential problem for a line-oriented coverage tool! that's fatal" ;-) FWIW, Ned Batchelder's 'coverage.py' does a good job with branch coverage. I haven't seen anything in this discussion which indicates that binding expressions will change that at all.
Coverage.py can measure branch coverage, but it is still line-oriented. There's no support for conditionals and branches within a line (though I've done some wicked hacks to experiment with it: https://nedbatchelder.com/blog/200804/wicked_hack_python_bytecode_tracing.ht...).
It's entirely true that binding expressions don't change this situation at all, EXCEPT that the entire point of binding expressions is to be able to express in one statement what used to take more than one. With binding expressions, actions may be coverage-hidden within one statement that without them would have been coverage-visible in more than one statement.
I'm not sure that's an argument against binding expressions, but we should at least acknowledge that the motivation for them is to provide the option to write fewer, longer statements. That option is not always a good idea, for a variety of reasons.