The worst thing about exposing yourself to Python (or other, similar languages) is that later on, you no longer can love Obj-C after seeing BS like this (actual messages printed out during unit tests.) Code: ("1") is not equal to ("1") ("2") is not equal to ("2") ("2") is not equal to ("2") ("1") is not equal to ("1") What was the actual problem? The method on the left was returning NSUIntegers and the value it was being compared to was just "1" or "2". To make my tests pass, I had to explicitly cast the values on the right to NSUIntegers. I could understand* if floating points were involved, but how the heck is it messing this up? Integral value on the left and integral value on the left. The fact one is unsigned should make no difference. The only difference I can see is one is 32-bit wide while the other is 64-bit wide, but I thought that was an implementation detail that was automatically handled? *Sort of. Again, it seems like an implementation detail that aught to be handled automatically. I can think of numerous examples of similar problems in C, C++, and Java, but rarely have I thought that Python had retarded issues like this. About the only thing I run into Python that I find frustrating is when a method expects, for example, a list of strings, but instead I pass in just a single string. At which point I think, jeez, I wish I was working with jQuery, which tends to automatically handle items as being lists of length 1.