Booleans (was: Conditional operator in Python?)

[Steve Holden]

"Erik Max Francis" <max at alcyone.com> wrote in message
news:3ACDF088.88E7406A at alcyone.com...
> "Russell E. Owen" wrote:
>
> > However, the broader issue is of a separate boolean type used for all
> > logical operations. I personally think it's quite messy and confusing
> > that any value has an associated logical value (e.g. 0 is false, any
> > other integer is true, "" is false, any other string is true, etc.).
> > But
> > as I said in my previous posting, it's a widely used construct that
> > doesn't seem to screw up languages too badly. And there's no way to
> > change this in Python without breaking tons of code.
>
> This is true.  I would be mollified if there were a builtin operator
> that tests truth in the same way that if ...: does.  It would be named
> something like bool or boolean and would return a 0 or 1 and nothing
> else:
>
> >>> bool(0)
> 0
> >>> bool(3)
> 1
> >>> bool('hello')
> 1
> >>> bool('')
> 0
> >>> bool([])
> 0
> >>> bool([1])
> 1
> >>> bool(None)
> 0
>
Well, even *I* can write that one:

def bool(x):
    if x: return 1
    else: return 0

You can omit the "else: " for brevity, if you like.  Since you seem to be
quoting interpreter output, you obviously wrote an equivalent function
yourself.  However, you have no need to...

> I'm actually surprised nothing like that already exists in the language
> (maybe it does and I'm just missing it), since being able to test for
> truth in the same way that if ...: would seem a common application.
>
...since operator.truth() already does it. See, the time machine flies into
action yet again! Guido *knew* you would want this. Can we take it you are
mollified?

>>> import operator
>>> bool = operator.truth
>>> bool(0)
0
>>> bool(3)
1
>>> bool('hello')
1
>>> bool('')
0
>>> bool([])
0
>>> bool([1])
1
>>> bool(None)
0

> That at least makes the conditional operator workaround somewhat less
> ugly:
>
>     [a, b][bool(x)]
>
I believe it has now been pointed out several times that this would*not* be
equivalent to the C conditional operator, because it evaluates both
expressions before selecting them according to the truth value. Close, but
no cigar.

> > Regarding your boolean class, could you explain the value to adding
> > "don't know" to it? I can imagine it has its uses, but it sounds like
> > a
> > different problem domain than standard conditional logic such as
> > if/then/else. If you're aiming for fuzz logic then presumably you'd
> > want
> > more choices than simply true, false and don't know.
>
> Agreed, it has limited application, so limited in fact that someone
> needing such behavior (true, false, don't know) would be better off
> writing their own Boolean type that behaved the way they wanted.
>
Anyone who has messed around with multi-valued logics (even the three-valued
TRUE, FALSE, NULL of SQL) will tell you that you had better sharpen your
mind before you tangle with them. The law of the divided middle is so
ensconced in most people's thinking that it's *very* difficult to chop
N-valued logic where N>2.

and-what-about-an-if:-then:-maybe:-perhaps:-sometimes:-frequently:-else:-sta
tement-ly y'rs  -steve