[Tutor] “has a value of True” versus “evaluates true”

Steven D'Aprano steve at pearwood.info
Thu Nov 13 05:10:48 CET 2014

On Wed, Nov 12, 2014 at 01:25:15AM +0000, Danny Yoo wrote:

> Just to note; not all programming languages do it this way.  Python is
> fairly permissive in what it allows to be "truthy".  See:
> https://plus.google.com/+ShriramKrishnamurthi/posts/4qvvKYC1R8Y for a brief
> survey of what many other programming languages do.
> It can be confusing and bug-prone as heck.

I strongly disagree, especially since Python has an excellent model for 
deciding truthiness by default: something versus nothing.

Python's treatment of true/false values matches the standard Python 
philosophy of duck-typing. Rather than require a fixed type of object, 
say a duck, Python generally allows you to use anything which behaves 
sufficiently duck-like for your purposes. All Python objects quack like 
bools, and truthiness is a fundamental property of all Python objects.

Unlike some languages, which choose confusing and arbitrary sets of 
values that count as truthy or falsey, Python encourages a simple 
distinction, something versus nothing. Values which represent some kind 
of "nothing" are falsey:

- numeric zeroes, e.g. 0, 0.0, 0j, Decimal(0)
- empty containers, e.g. [], (), {}, set(), frozenset()
- empty strings, e.g. "", u""
- None

Values with represent something are truthy:

- non-zero numbers
- non-empty containers
- non-empty strings
- arbitrary objects

> For myself, I usually want as restrictive an approach as possible with
> respect to what things are considered "truthy".  If I'm in a boolean
> context, I will explicitly make the expression being tested be either True
> or False, and that's it.

Do you duck-type other kinds of values, or do you insist on explicitly 
forcing everything to be a single kind of object?

Do you write "len(list(sequence))", or just "len(sequence)"?

If you allow len() to duck-type its argument, why not allow duck-typing 

> That way, I know I won't get into shaky waters.
> I program in multiple languages: I don't want to spend brain power
> remembering yet another a truth table about truth.

It's your choice to program in multiple languages. Presumably you get 
some benefit from that. The cost of using different languages is that 
they are different: they have different semantics, syntax, libraries, 
they use different idioms, require you to write different code. If you 
don't like that, don't write code in different languages.

Do you complain that it is "confusing and bug-prone as heck" that the 
same operation might be spelled any of these ways?

x len
len x

All languages makes choices. Complaining that a specific choice is hard 
to use, inconsistent with the rest of the language, confusing or 
bug-prone is okay. Complaining that different languages have different 
semantics is, well, silly. Different programming languages are 
different, that's why they're different languages and not all FORTRAN.

Anyone who writes:

    if bool(x): ...

in Python instead of just "if x" is just exposing their own confusion. 
Think about it: calling bool() explicitly does *nothing* that Python 
doesn't already do, that's as silly as writing:

result = int(23) + float(42.5)

If they write this:

    if bool(x) == True: 

that's even more foolish. Why stop there?

    if bool(x) == True == True: 
    if bool(x) == True == True == True: 
    if bool(x) == True == True == True == True:
    # I never know where to stop...

It may be acceptable to specifically accept *only* True and False under 
some (hopefully rare) circumstances:

    if x is True: ...
    elif x is False: ...
    else: raise TypeError

but if you insist in trying to force Python to be a poor emulation of 
Pascal, one wonders why you don't just use Pascal.

> To quote: "Let your statement be: 'Yes, yes', or "no, no': anything beyond
> these is of evil."

"Have you stopped abusing small children yet?"


More information about the Tutor mailing list