5 ms·

That is entirely consistent with how truthiness works in Python. The function does not claim to parse strings, that is how you get YAML Norway. Do you think th

That is entirely consistent with how truthiness works in Python. The function does not claim to parse strings, that is how you get YAML Norway. Do you think there should be different results for bool("no"), bool("false"), bool("heckno!"), bool("heckyes!")? Edit: should have included internationalization: bool("nein!")

moffkalast 1y ago
Honestly once you really think about it just about nothing about these decisions ever makes any real sense which is why JS is made fun of constantly. It's nonsense functions running on nonsense data. "if some_non_bool_value:" should not be valid syntax and truthy and falsy is a concept that would get you locked up in an asylum if you decided to explain it to a doctor.
crazygringo 1y ago
> The function does not claim to parse strings But it's entirely reasonable to think it would. I honestly don't understand why it wouldn't, because: >>> int("35") 35 >>> float("3.5") 3.5 >>> bool("False") True If casting from a string to a type works with ints and floats, why not with bools? What possible justification is there? And of course it doesn't need to work for "no" or "heckno!", that's silly. But it sure seems like it ought to work on whatever the official string representation is. And not produce: >>> bool(str(False)) True I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now.
- 3eb7988a1663 1y ago
  prefer bool() threw an exception on receiving a string, rather than act the way it does now. That breaks the truthiness cornerstone of the language. You can write a = 1 # or [], (), "yo", "false", 3.2, MyFooClass(), (1,), False if a: fire_ze_missles() else: declare_peace() Upon encountering `a`, Python is evaluating bool(a). If that no longer works for strings, you now need a separate code path for determining a non-empty string. It can short-circuit the brain upon reading a word that you know means false, but the Python rules are consistent. "Empty" is False, everything else is True.
  - moffkalast 1y ago
    You can write that yes, but I'm calling the police.
    - jonathrg 1y ago
      You can't go calling the police on people for writing idiomatic Python code.
- tmh88j 1y ago
  > If casting from a string to a type works with ints and floats, why not with bools? What possible justification is there? > I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now. They serve fundamentally different purposes. bool() is a truthiness check and not a type cast like int() and float(). It seems like a lot of people take issue with the name, because it was called something like istruthy() the discussion about it wouldn't be happening.
  - akoboldfrying 1y ago
    > bool() is a truthiness check and not a type cast like int() and float(). It seems like your issue is with the name of the function, because if it was more aptly named to something like istruthy() this discussion wouldn't be happening. Right, the bug is in the inconsistent naming. It's roughly as bad as having arithmetic operators named +, -, *, / that perform arithmetic as usually understood, except that + actually performs XOR and is documented to do so.
    - tmh88j 1y ago
      > Right, the bug is in the inconsistent naming. The comment I responded to didn't seem to realize that because they asked why it behaves the way it does, so I explained.
- Jtsummers 1y ago
  > 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" ""
- jonathrg 1y ago
  > If casting from a string to a type works with ints and floats, why not with bools? What possible justification is there? There's no type casting in Python. int(), float() and bool() just create objects of their respective types, passing the arguments to the initializer. They are not fundamentally different from, say, PostgresqlDriver() in this regard. Different classes will provide different ways to construct objects depending on what is most useful. For int and float, the most useful thing to do when receiving a string is to parse it; for bool, the most useful thing to do is to check its truthiness; for PostgresqlDriver, the most useful thing to do is to interpret it as a database URL and connect to it.
  - crazygringo 1y ago
    > There's no type casting in Python. If you search "type casting in Python" you will find lots of articles explaining how to use int(), str(), etc. to cast. This is a common and well-documented concept, even if it's different under the hood from e.g. C. The idea that you'd name a function bool() and have it act differently is a deeply confusing design decision that it's understandable people would get misled by and frustrated with. This is a function named after a fundamental type. It's not a random user-defined constructor.
    - bb88 1y ago
      If we do it that way, we have worse problems. if "False": # What do you expect? True or False? print("True") else: print("False") bool() is consistent with how "truthiness" happens in python. Otherwise we end up with the YAML norway problem. if bool("False"): print("True") else: print("False") # This would be different if we landed here. And that would be different behavior then the above -- creating a nasty inconsistency. Honestly it's not that hard to write something that looks like this: def str_to_bool(val: str) -> bool: return val.lower() in ["yes", "true", "1"]
    - jonathrg 1y ago
      bool() is not a function named after a fundamental type. bool is a type. As with any type, you can call bool(...) to construct a new object of that type. https://docs.python.org/3/library/functions.html#bool https://docs.python.org/3/library/functions.html#bool A good tutorial will reflect this fact and use appropriate language. Both the idea that you can "cast", and the idea that bool is a function, are misunderstandings rooted in the idea that Python should be like C in all ways.

moffkalast 1y ago

Honestly once you really think about it just about nothing about these decisions ever makes any real sense which is why JS is made fun of constantly. It's nonsense functions running on nonsense data. "if some_non_bool_value:" should not be valid syntax and truthy and falsy is a concept that would get you locked up in an asylum if you decided to explain it to a doctor.

crazygringo 1y ago

> The function does not claim to parse strings But it's entirely reasonable to think it would. I honestly don't understand why it wouldn't, because: >>> int("35") 35 >>> float("3.5") 3.5 >>> bool("False") True If casting from a string to a type works with ints and floats, why not with bools? What possible justification is there? And of course it doesn't need to work for "no" or "heckno!", that's silly. But it sure seems like it ought to work on whatever the official string representation is. And not produce: >>> bool(str(False)) True I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now.

3eb7988a1663 1y ago
prefer bool() threw an exception on receiving a string, rather than act the way it does now. That breaks the truthiness cornerstone of the language. You can write a = 1 # or [], (), "yo", "false", 3.2, MyFooClass(), (1,), False if a: fire_ze_missles() else: declare_peace() Upon encountering `a`, Python is evaluating bool(a). If that no longer works for strings, you now need a separate code path for determining a non-empty string. It can short-circuit the brain upon reading a word that you know means false, but the Python rules are consistent. "Empty" is False, everything else is True.
- moffkalast 1y ago
  You can write that yes, but I'm calling the police.
  - jonathrg 1y ago
    You can't go calling the police on people for writing idiomatic Python code.
tmh88j 1y ago
> If casting from a string to a type works with ints and floats, why not with bools? What possible justification is there? > I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now. They serve fundamentally different purposes. bool() is a truthiness check and not a type cast like int() and float(). It seems like a lot of people take issue with the name, because it was called something like istruthy() the discussion about it wouldn't be happening.
- akoboldfrying 1y ago
  > bool() is a truthiness check and not a type cast like int() and float(). It seems like your issue is with the name of the function, because if it was more aptly named to something like istruthy() this discussion wouldn't be happening. Right, the bug is in the inconsistent naming. It's roughly as bad as having arithmetic operators named +, -, *, / that perform arithmetic as usually understood, except that + actually performs XOR and is documented to do so.
  - tmh88j 1y ago
    > Right, the bug is in the inconsistent naming. The comment I responded to didn't seem to realize that because they asked why it behaves the way it does, so I explained.
Jtsummers 1y ago
> 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" ""
jonathrg 1y ago
> If casting from a string to a type works with ints and floats, why not with bools? What possible justification is there? There's no type casting in Python. int(), float() and bool() just create objects of their respective types, passing the arguments to the initializer. They are not fundamentally different from, say, PostgresqlDriver() in this regard. Different classes will provide different ways to construct objects depending on what is most useful. For int and float, the most useful thing to do when receiving a string is to parse it; for bool, the most useful thing to do is to check its truthiness; for PostgresqlDriver, the most useful thing to do is to interpret it as a database URL and connect to it.
- crazygringo 1y ago
  > There's no type casting in Python. If you search "type casting in Python" you will find lots of articles explaining how to use int(), str(), etc. to cast. This is a common and well-documented concept, even if it's different under the hood from e.g. C. The idea that you'd name a function bool() and have it act differently is a deeply confusing design decision that it's understandable people would get misled by and frustrated with. This is a function named after a fundamental type. It's not a random user-defined constructor.
  - bb88 1y ago
    If we do it that way, we have worse problems. if "False": # What do you expect? True or False? print("True") else: print("False") bool() is consistent with how "truthiness" happens in python. Otherwise we end up with the YAML norway problem. if bool("False"): print("True") else: print("False") # This would be different if we landed here. And that would be different behavior then the above -- creating a nasty inconsistency. Honestly it's not that hard to write something that looks like this: def str_to_bool(val: str) -> bool: return val.lower() in ["yes", "true", "1"]
  - jonathrg 1y ago
    bool() is not a function named after a fundamental type. bool is a type. As with any type, you can call bool(...) to construct a new object of that type. https://docs.python.org/3/library/functions.html#bool https://docs.python.org/3/library/functions.html#bool A good tutorial will reflect this fact and use appropriate language. Both the idea that you can "cast", and the idea that bool is a function, are misunderstandings rooted in the idea that Python should be like C in all ways.