[PhantomGremlin]

Here's a little bit of a conspiracy theory for you. There's an old saying: "there are no coincidences on Wall Street". Not with the amounts of money that are involved.

I think something similar should apply to critical security code. This reminds me of when someone tried to add the following to the Linux kernel:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL;

Oops, is that "uid == 0", or is that "uid = 0"? Yet another "typo" that couldn't happen in Python.

[hahainternet]

How could this not happen in Python?

[nickbauman]

Good question, even though Python doesn't allow assignment in an expression, but for this reason I put the constant on the left side of the comparison no matter what language I use.

[manojlds]

Because assigning in if would be a syntax error in Python.

[PhantomGremlin]

Python does not allow an assignment to occur within an expression. They deliberately chose that restriction, to avoid that hard-to-see bug.

[nuxi]

True, but in languages with operator overloading you (may) end up with other issues. Unless you look at the source you have no idea what the '==' operator will do.

[staticfish]

I have always wondered why all languages don't enforce this?

[joveian]

Because it is often really convenient, particularly with a simple macro preprocessor like cpp but in other circumstances too. I like gcc's approach of forcing you (if you have the right warning enabled) to put an extra pair of unnecessary parentheses around assignments in expressions.

[cnvogel]

because, for example in C, such a incompatible change would alienate most developers used to the very ideomatic

        if((val = function(args)) != expected)
            return val;

[lectrick]

A better solution is gcc's which forces you (if you enable the restriction) to put an extra pair of parens around inline assignments.

[dspeyer]

The parenthesis in this attack are sufficient to prevent that warning.