Python truthiness helper mixing strings and booleans illustrates naïve input validation humor
Description
Screenshot of a dark-themed code editor showing two lines of Python with syntax highlighting. Line 1 reads: "def is_truthy(s):" in which the keyword "def" is aqua, the function name "is_truthy" light blue, and parameters white. Line 2 is indented and reads: "return s in ['True', 'true', 'Yes', 'yes', True]" with "return" in yellow, brackets in white, the four string literals in pink, and the bare Boolean literal True in bold cyan. The snippet attempts to decide whether a value should be considered truthy by checking membership in a heterogeneous list that mixes strings and a Boolean, creating an obvious type-comparison pitfall and ignoring other common cases like "1" or different casing. Seasoned developers will recognize this as a code smell demonstrating poor input validation, hidden bugs from type coercion, and the classic need for clearer normalization logic or a mapping table
Comments
32Comment deleted
Our “robust” truthiness check: a list that treats 'yes', 'True', and, thanks to Python’s bool-int equality, the integer 1 as the same flag. Nothing like shipping a feature where page views accidentally enable production mode
After 20 years in tech, I've learned that 'boolean' is just a suggestion - it's really a string enum with infinite possible values, each client having their own creative interpretation of what constitutes 'true'
Ah yes, the classic 'is_truthy' function that returns True when you pass it the string 'True' but False when you pass it the string 'False' - because apparently we're still debugging that YAML parser from 2015 where everything became a string. This is what happens when your API accepts form data, JSON, and carrier pigeons all through the same endpoint, and you've given up on type hints because 'Python is dynamically typed anyway.' Bonus points: this will fail spectacularly when someone inevitably passes 'TRUE', '1', or 'y', leading to a 3 AM incident where the root cause is 'case sensitivity in boolean string parsing' - a phrase that should never exist in production code but somehow always does
Accepts 'True', 'Yes', and - thanks to bool==int - the number 1; enjoy your retries=1 query param enabling the production feature flag
def is_truthy(s): return s in ['True','true','Yes','yes', True] - when you try to parse booleans and accidentally ship YAML 1.1 semantics; bonus: 1, 1.0, and np.bool_ also count as “yes” because bool is int
Because strict typing is for interviews; prod configs demand diplomatic truth parsing
What about "y", " Y" and "why not?" ? Comment deleted
What about 1? Comment deleted
What about sqrt(1) and 1^n? Comment deleted
What about ln(e) and -cos(pi)? Comment deleted
What about f(x)=1? Comment deleted
=1 Comment deleted
if(eval(s) in [1,.... Comment deleted
eval is dangerous Comment deleted
No shit Comment deleted
eval is evil. Comment deleted
Nah man you are wrong just use it properly: eval(“(()=>{ usrNm = \”” + document.getElementById(“usernamebox”).Text + “\”;})();”); Comment deleted
I'm pretty sure we also need a byte array/hash of this image Comment deleted
where are 1,2,… Comment deleted
it is not haskell Comment deleted
python Comment deleted
there is no laziness Comment deleted
and by this term what are we tryna result in? Comment deleted
Hey, what about everything that is not zero/null? Comment deleted
Maybe "No" is not truthy Comment deleted
You say that to char No[] = "No"; printf("%s\n", (No ? "Yes!" : "Oh no!")); 😝 Comment deleted
What about stop using this shitty lang for dumb nerds? Comment deleted
What about sqrt(a*a+a*a)? Comment deleted
yaml be like Comment deleted
it says perhaps in Ukrainian Comment deleted
Perhaps... Comment deleted
What about !0 ? Comment deleted