Curious assignment behaviour

David Bolen db3l at
Wed Oct 10 21:14:19 CEST 2001

"Tim Peters" < at> writes:

> [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.

I've got to admit to being a big fan/user of assignment as an
expression in my C code, so I also miss it in Python at times.  But on
the whole I think Python probably made the right choice, at least
while "=" and "==" are the tokens in question.

I know I've myself created this bug a lot more than once or twice in C
code in my past 17 years or so, and have also seen it in many others
code.  Within my own code, the big difference over time has been being
quicker to notice since I was aware of it, so it rarely did much
damage outside of a debug run.  But when first trying to diagnose
foreign code it could take quite a while to isolate and waste a lot of

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

Yeah, it's almost wierd how easy it is to stare at an expression like
this and simply not notice the problem.

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

Yeah, it's one of those points where being burned once can hurt more
and waste more time than having the functionality available will help
or save time even over a very long time.

-- David
 \               David Bolen            \   E-mail: db3l at  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \

More information about the Python-list mailing list