4 ms·

Why not do `x == False` then? Arguing about a language not being as strongly typed when you're not being as explicit about your own types seems pretty roundabou

• masklinn 11y ago
  You want `x is False`, because `0 == False`: Python didn't originally have integers so `0` and `1` were used for `False` and `True` respectively. In order not to break existing code using equality comparisons (rather than implicit truthiness) or typechecking, when booleans were introduced `bool` was made a subclass of `int`, and `False` and `True` equal to respectively `0` and `1`. This is one of the warts which wasn't changed in Python 3.
• crdoconnor 11y ago
  >Why not do `x == False` then Because it's no more explicit than "not x" and because it's 5 characters longer. There's always a trade off to be made between clarity and verbosity. Judging by the number of bugs I've squashed caused by the developer either not realizing or simply forgetting that ("", 0, 0.0, midnight, False, [], {}, None) all resolve to false, I've come to believe this is one of those times where the clarity should probably take precedence. You can go to the other extreme by making everything explicitly statically typed which will make your code much more verbose (e.g. see Java). I believe that trade off isn't worth it either, despite the small increase in type safety.
  • masklinn 11y ago
    > You can go to the other extreme by making everything explicitly statically typed which will make your code much more verbose (e.g. see Java). Java is not an example of a good static typing implementation and is not exemplar of verbosity in modern statically typed languages.