[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Ned Batchelder]

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.html).

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.

--Ned.