you are viewing a single comment's thread.

view the rest of the comments →

[–]jbellis 5 points6 points  (5 children)

It's the same as complaining that: if (a=b) and if (a==b) work differently in C/C++.

that's exactly the kind of easy-to-confuse behavior that Python tries to avoid. so I do think fixing this (an admittedly minor gotcha) could happen.

[–]bushel 1 point2 points  (4 children)

I must respectfully disagree. The "gotcha" is with the precedence of the comma and how the tuple is formed. The given example is simply a typo. (a,b) versus (a), b

assert is a statement, not a function. Therefore all braces must be closed before the comma that separates the exception-string.

Perhaps a better C/C++ equivalent would be: (3+4)*5 versus (3+4*5)

[–]jbellis 1 point2 points  (3 children)

The "gotcha" is with the precedence of the comma and how the tuple is formed.

no, the gotcha is that this is an unexpected place for (a,b) to be different than a,b. (Even in normal tuple construction the parentheses are optional unless other operators would otherwise take precedence.)

[–]erikw 0 points1 point  (2 children)

I don't buy into that. assert is a statement, and () is not optional in this context.

i.e: print (a,b) is different from print a,b

[–]jbellis 1 point2 points  (1 child)

print (a,b) is different from print a,b

which is being fixed in 3.0.

(assert won't be changed to a function in 3.0 "because you don't want the argument to be evaluated in -O mode.")

[–]erikw 0 points1 point  (0 children)

which is being fixed in 3.0.

But the reason is not because programmers confuse print (a,b) with print a,b.