4 ms·

Yeah python deserves a good bashing as well, it's about as bad as JS in this regard. I mean for bool("false") resolves to True ffs.

bnchrch 1y ago
Don't forget its transitive dependencies creating non-deterministic builds
3eb7988a1663 1y ago
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.
librasteve 1y ago
yeah in raku, i checked say False.so; #False
- Jtsummers 1y ago
  If I understand raku correctly, the Python example would be more like this: say "False".Bool or: say "False".so Both of which display True. Leaving out the quotes means you're testing something else entirely. Note that the Python example is converting (via `bool`) a string with the text "false" (which would make more sense as "False" which is the actual name of `False` in Python) into a boolean value. It's consistent with how Python behaves, in that the empty string (like in Raku from what I can tell) is false-y and non-empty strings are truth-y. It would be weird to have this use the else branch: if bool("False"): ... else: ... But not this: if "False": ... else: ...
  - gpderetta 1y ago
    As mentioned else thread, the problem is not so much that book("false") evaluates to true, which is consistent with a lot of the language, but that int("1") evaluates to 1. Generally python is much better than some other dynamic languages in avoiding stringly typed confusion, but the convenience of the int from string constructor set expectations that the rest of the language can't sanely meet. String to type construction should have been relegated to a dedicated syntax in all cases.
  - librasteve 1y ago
    thanks for the correction

bnchrch 1y ago

Don't forget its transitive dependencies creating non-deterministic builds

3eb7988a1663 1y ago

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.

librasteve 1y ago

yeah in raku, i checked say False.so; #False

Jtsummers 1y ago
If I understand raku correctly, the Python example would be more like this: say "False".Bool or: say "False".so Both of which display True. Leaving out the quotes means you're testing something else entirely. Note that the Python example is converting (via `bool`) a string with the text "false" (which would make more sense as "False" which is the actual name of `False` in Python) into a boolean value. It's consistent with how Python behaves, in that the empty string (like in Raku from what I can tell) is false-y and non-empty strings are truth-y. It would be weird to have this use the else branch: if bool("False"): ... else: ... But not this: if "False": ... else: ...
- gpderetta 1y ago
  As mentioned else thread, the problem is not so much that book("false") evaluates to true, which is consistent with a lot of the language, but that int("1") evaluates to 1. Generally python is much better than some other dynamic languages in avoiding stringly typed confusion, but the convenience of the int from string constructor set expectations that the rest of the language can't sanely meet. String to type construction should have been relegated to a dedicated syntax in all cases.
- librasteve 1y ago
  thanks for the correction