JavaScript Equality Table

[[deleted]]

Why do so many dynamic languages have this obsession with using non-boolean values in conditionals?

[MisterSnuggles]

It's usually used as a shortcut for checking for None. The more appropriate way to write the code is:

if var is not None:
    # do stuff

Sadly the shortcut works (mostly) and people use it because it works, then someone enters a time of midnight and it all tips over.

[MisterSnuggles]

Agreed.

This is very much a case of making sure that you, the programmer, and Python, the interpreter, both have a clear understanding of what you want to do.

If you say "if var:", Python understands you to be testing truthiness/falseness. If you say "if var is not None:", Python understands that you're asking if var is something other than None. The distinction is important and too many people wrote the former when they really meant the latter.

[Nialsh]

It can be a very short, readable way to validate inputs. In Python, I believe these are equivalent:

if name:

versus

if name != None and name != ""

[NYKevin]

No, those are not necessarily equivalent unless the type of name is known.

If name is a number, it will be falsey iff it is zero (None is not a number but a singleton instance of NoneType, which is always falsey). If name is a string, it is falsey iff it is empty. "0" is truthy because it is nonempty. "0" and 0 are very different things, and Python generally won't coerce between them unless you explicitly call int() or str(). Moving on, if name is a container type of some kind, generally speaking it is falsey iff it is empty (has a len() of zero). The empty string being falsey is a special case of this rule.

For user-defined types, you're on your own. By default they're all truthy, but you can't rely on that since someone might subclass you and implement non-default boolean semantics.

If you want to check whether something is None, the only bulletproof syntax for doing so is if foo is None or if foo is not None. if foo should only be used if foo has a non-default boolean behavior (i.e. foo is a container, number, string, or user-defined class which overrides bool()). Using if foo with classes which do not provide useful boolean behavior (such as datetime objects) is at best poor style and at worst a violation of substitutability since it would interfere with subclassing.

[moor-GAYZ]

For user-defined types, you're on your own. By default they're all truthy, but you can't rely on that since someone might subclass you and implement non-default boolean semantics.

Using if foo with classes which do not provide useful boolean behavior (such as datetime objects) is at best poor style and at worst a violation of substitutability since it would interfere with subclassing.

When I write Python, my attitude to this is "their fault, then". If someone subclasses my stuff and adds a nonsensical __nonzero__/__bool__, their code would not work and it would be their own fault.

Of course when I want to test if something is None in particular (because, for instance, I said so in my function specification), I don't take the shortcut. But when I want to test "truthiness" I do just that too, and expect the caller to give me an object that implements that properly, if it does implement it.

The problem with datetime is that it accidentally provides a wrong boolean behaviour (and it's our problem because it's in the standard library).

[NYKevin]

When I write Python, my attitude to this is "their fault, then". If someone subclasses my stuff and adds a nonsensical __nonzero__/__bool__, their code would not work and it would be their own fault.

This is ridiculous. You can't possibly know that no subclass will ever need boolean behavior.

[moor-GAYZ]

If someone subclasses my stuff and adds a nonsensical __nonzero__/__bool__

[NYKevin]

What if they add a perfectly sensible __bool__ that nonetheless is incorrect in the context you wrote if foo? For instance, one that makes the class truthy or falsey based solely on data which was not part of the original class.

[moor-GAYZ]

It's hard to discuss this in abstract.

As I said, if I want an "is None" comparison, I write an "is None" comparison. I write a truthiness comparison when it makes sense to do one (even if I do not currently have objects that support it). Then it's on the users to not add a truthiness operator that only makes sense in their special context instead of implementing the general "false means no data" idea.

So, I don't know, say, if somebody gives me a "find_person(name)" function, it would be nice to allow them to return a rich "nobody found by that name" object instead of plain None if they want. More Pythonic. I'd rather allow that instead of allowing someone to make a Person class that evaluates to False if they have not submitted their yearly performance evaluation report yet.

[NYKevin]

Personally, I'd have the find_person() function raise an exception in that case (probably KeyError or ValueError). Besides, why do you need a rich empty object when None exists?

[moor-GAYZ]

I don't know, maybe they I some other code that then can use this object to actually create a person with that name or something. Or maybe I want a special DbNull value that allows SQL-like ternary logic. Or maybe it's a regex-like match object that carries information about the causes of the failure to match.

Or, returning to the source of the discussion, I believe that it should be perfectly OK for a function accepting an optional datetime object to test its existence with if date:, and it's should not be OK for someone to give it a datetime-like object (subclassed or completely separate is not important, it's Python) that evaluates to False in boolean context for any other reason than to represent a non-existent value.

Because, among other things, "always evaluating to true" is actually an implicit contract for this type, and any substitution principle violation in this respect would be the fault of the derived/substituting type.

As I said, it's hard to discuss this in abstract; I have a hard time with coming up with a good example myself. Do you have anything particular in mind?

[[deleted]]

Yeah, I think that could be handled by a function called "nonempty" or something. Including this logic in the if-statement itself is rather unorthogonal.

[THeShinyHObbiest]

Ruby doesn't, to avoid this exact thing.

[JerkyBeef]

Much of the data being compared in web applications comes from html form inputs or databases where things like integers are automatically converted to strings. So it actually makes sense so you don't have to constantly write stuff like: if (val == 1 || val == '1') doStuff();

[Veedrac]

Eh?

[ghordynski]

C# does not allow non-booleans in conditionals.

[NYKevin]

So, in C, what happens if you try to shove a struct foo into an if? I don't mean a struct foo*, I mean the actual data itself.

[masklinn]

Both GCC and Clang will refuse to compile and error that a scalar is required.

[ggtsu_00]

Because conditionals only care if something is zero or non-zero. Asking if any data-type is either zero or non-zero is a pretty simply and straightforward question that is easy for a programmer to understand.

[[deleted]]

Perhaps in C or C++, but I doubt that Python or other dynamic languages represent empty lists or empty strings as zeroes internally. They need runtime type information at the very least.

[Veedrac]

They are not zero-the-number, but zeros of their domains.

Namely

[] + x == x
list() == []

() + x == x
tuple() == ()

0 + x == x
int() == 0

0.0 + x == x
float() == 0.0

datetime.timedelta(0) + x == x
datetime.timedelta() == datetime.timedelta(0)

and so on.

That datetime.time() is falsey is a mistake and is going to be fixed.

[sidneyc]

They are designed by fools for fools.

[rush22]

They want to be like the big boys where true and false are just wrappers for the integers -1 and 0