[Python-ideas] Wg: Re: If branch merging

[Nick Coghlan]

On 7 June 2015 at 22:55, s.krah <stefan at bytereef.org> wrote:
> Andrew Barnert abarnert at yahoo.com  wrote:
>
>>> In C I've mistyped this perhaps twice
>
>> Then you must be an amazing programmer. Or maybe you don't code in C very
>> much.
>
> Or maybe I don't pontificate on mailing lists all day long.

No need for that, folks. (And Stefan, you're definitely on the first
half of Andrew's either/or statement there - not everyone is going to
be aware that you wrote cdecimal, redesigned the memoryview
implementation, etc).

The C/C++ embedded assignment construct *is* a major source of bugs
unless you really know what you're doing, which is why the compiler
developers eventually relented and introduced a warning for it. It's a
construct that trades clarity for brevity, so using it isn't always a
clear win from a maintainability perspective. It's also heavily
reliant on C's behaviour where assignment expression have a truth
value that matches that or the RHS of the assignment expression, and
the resulting longstanding conventions that have built up to take
advantage of that fact.

In Python, we've never had those conventions, so the alignment between
"truth value you want to test" and "value you want to work with" isn't
anywhere near as strong. In particular, testing for None via bool() is
considered incorrect, while testing for a NULL pointer in C++ with a
truth test is far more common.

To get the same kind of utility as C/C++ embedded assignments provide,
you really do need arbitrary embedded assignments. Only being able to
name the result of an if or while clause would be too limiting to be
useful, since you'd still need to find other ways to handle the cases
where the value to be tested and the value you want to work with
aren't quite the same.

That's why this particular idea is oft-discussed-but-never-accepted -
there are certain looping and conditional constructs that *do* become
more convoluted in its absence, but the benefit of leaving it out is
that those more convoluted constructs are needed to handle the general
case anyway, so the special case would be an additional thing to learn
that wouldn't actually make the language substantially more expressive
than it already is.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia