3 ms·

> I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now. `bool` would have no value if it threw an erro

> I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now. `bool` would have no value if it threw an error in this case because if strings can't be passed to it, then no other type would sensibly work either. It would basically just become `bool(False) -> False` and `bool(True) -> True`.

crazygringo 1y ago
> because if strings can't be passed to it, then no other type would sensibly work either It's pretty standard to convert integers to bools, where 0 becomes False and everything else becomes True. That is absolutely sensible and useful current behavior.
- Jtsummers 1y ago
  Right. Zero-values become False (empty set, empty string, 0, etc.) and non-zero-values become True. So we agree bool is consistent then.
  - crazygringo 1y ago
    Nope, because str(False) produces "False", not "". Not consistent at all. There's nothing consistent about bool(str(False)) == True. It's standard in computing for zero integers to represent False. Heck, bool is a subclass of int. Extending that to the length of strings is where things start to go off the rails in terms of consistency... and why you would ever even want that is beyond me.
    - 3eb7988a1663 1y ago
      Sounds like your complaint is with str() and not bool(). Which becomes a different issue - what do you think str(True) and str(False) should produce. Integer representations? That then makes other things unintuitive with changing the form of a boolean. print(0, 1, False, True) # today: 0 1 False True # as ints: 0 1 0 1 # new str: 0 1 "True" ""
      - crazygringo 1y ago
        No, my problem is with bool(). str(False) == 'False' is entirely logical. So therefore bool('False') == False would be consistent. And bool('foo') would produce an exception the exact same way int('foo') and float('foo') already do. Who on earth thought it was a good idea that 'foo' could or should be interpreted as a boolean...?? The entire concept of 'truthiness' outside of ints is unhelpful. It's just asking for bugs. That the length of a string, rather than its content, should determine a boolean value is one of the more bizarre things I've come across in programming languages. Use len() if you want that. It's only 5 extra characters.

crazygringo 1y ago

> because if strings can't be passed to it, then no other type would sensibly work either It's pretty standard to convert integers to bools, where 0 becomes False and everything else becomes True. That is absolutely sensible and useful current behavior.

Jtsummers 1y ago
Right. Zero-values become False (empty set, empty string, 0, etc.) and non-zero-values become True. So we agree bool is consistent then.
- crazygringo 1y ago
  Nope, because str(False) produces "False", not "". Not consistent at all. There's nothing consistent about bool(str(False)) == True. It's standard in computing for zero integers to represent False. Heck, bool is a subclass of int. Extending that to the length of strings is where things start to go off the rails in terms of consistency... and why you would ever even want that is beyond me.
  - 3eb7988a1663 1y ago
    Sounds like your complaint is with str() and not bool(). Which becomes a different issue - what do you think str(True) and str(False) should produce. Integer representations? That then makes other things unintuitive with changing the form of a boolean. print(0, 1, False, True) # today: 0 1 False True # as ints: 0 1 0 1 # new str: 0 1 "True" ""
    - crazygringo 1y ago
      No, my problem is with bool(). str(False) == 'False' is entirely logical. So therefore bool('False') == False would be consistent. And bool('foo') would produce an exception the exact same way int('foo') and float('foo') already do. Who on earth thought it was a good idea that 'foo' could or should be interpreted as a boolean...?? The entire concept of 'truthiness' outside of ints is unhelpful. It's just asking for bugs. That the length of a string, rather than its content, should determine a boolean value is one of the more bizarre things I've come across in programming languages. Use len() if you want that. It's only 5 extra characters.