5 ms·

Have you used Python a lot? That's not how it works. Python is not weakly typed and "string" + 5 throws an exception.

• mercurial 12y ago
  Yes (though it treats 1 as True and 0 as False, which it really ought to avoid).
  • masklinn 12y ago
    Historical imperative though, for backwards compatibility with if some_bool == 1 or if isinstance(some_bool, int) written before the bool type was added (which only happened 2.3)
    • unwind 12y ago
      I dream of a language where booleans cannot be compared explicitly against literals, that would be awesome. I have powerful dislike for code like the future version of the above, i.e. if some_bool == True since that, in my mind's machine, just generates a bool result, which then (in the logic of the code) must be compared to True. If the result of == doesn't have to be compared, then why does some_bool? It's brutally inconsistent and fantastically annoying. Unfortunately, to many programmers it's also second nature to write such comparisons. Gaah. :(
      • masklinn 12y ago
        Equality might be used for other things, e.g. a map with boolean keys, stuff like that. So I don't think it would be workable. You could try removing Eq, Ord and TotalOrd from Rust's bool and see what breaks.
      • Dylan16807 12y ago
        >where booleans cannot be compared Sounds like a way to make XOR be a big pain. Or do you only want to ban comparing to literals? It can make things clearer to write something like "if bool==false" rather than "if not bool", especially when double negatives get involved. Only ban comparing to literal true? Sure, go for it. But then the language is more complex for no real benefit.