Curious assignment behaviour

[Tim Peters]

[Paul Rubin, on an expression assignment operator]
> Why on earth does it have to be different from the statement assignment
> operator?  What's wrong with
>
>   while x=get_next(): whatever(x)
>
> I just don't buy the rationale that using = instead of == is a big source
> of bugs.  In 25 years of hacking C code, I think I've seen that error
> maybe once or twice.

I suggest you're highly atypical here, Paul.  This was the very first of the
gotchas listed in Andrew Koenig's classic (late 80s) "C Traps and Pitfalls",
and has made nearly every list of C "deadly sins" I've seen since then.
I've wasted weeks of my own life helping people track this error down in C,
too often under extreme time or customer pressure.  The experience of the
other folks at PythonLabs is similar, so even if it's a disease you're
immune to, you can be sure this will never go in.

At my last employer, we had a miserable bug that went away in a debug build,
and analysis all but assured that *if* the only plausible cause were
actually occurring, a particular assert would have triggered in the debug
build.  But the assert didn't trigger, and a run under the debugger
confirmed the vrbl had its asserted value, so people looked elsewhere.
Oops!  The assert turned out to be the perversely self-fulfilling:

    assert(i = 1);

and multiple senior programmers with with many decades of industrial C
experience had stared at that multiple times without realizing the mistake.
A complicating factor was that the compiler complained about a raw "(i = 1)"
in control-structure contexts, so perhaps people were lulled into a false
security about this trap.

It only takes one of those to sour you on the idea for life.

dozens-to-spare-ly y'rs  - tim