News for hackers. Stuff that matters.

A comment on Parsing R code: Freedom of expression is not always a good idea (2012). Parent comment

Re:Parsing R code: Freedom of expression is not always a goo... by abirch on Tuesday June 14, 2022 @11:05AM (#31740572)
Truthy values go through most C type languages. Python included. bool(2) is True
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by qsort on Tuesday June 14, 2022 @11:08AM (#31740616)
Python goes even further beyond.

  >>> True + True
  2

  >>> True * 13 + (1 - False) * 17
  30
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by kgwgk on Tuesday June 14, 2022 @01:08PM (#31742529)
What you show there is that int(True) is one and int(False) is zero.

(The same happens in R, for what it's worth. as.integer(TRUE) is one and as.integer(FALSE) is zero and the operations you wrote work just he same.)

[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by tech2 on Tuesday June 14, 2022 @12:46PM (#31742113)
That's history coming back to bite it though. There was a period where the symbols True and False existed in Python but the bool class did not. True was _literally_ 1, and False was 0. Because of this, for backward compat, bool is a subclass of int.
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by nomilk on Tuesday June 14, 2022 @11:10AM (#31740633)
TIL. Also in python bool("a") is True, whereas in R as.logical("a") is NA.
[ Parent | on HN ]