Why bool( object )?

[Aaron Brady]

On Apr 28, 9:54 pm, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Tue, 28 Apr 2009 11:59:18 -0700, Aaron Brady wrote:
> >> To steal an idiom from Laura: Python has a float-shaped Nothing 0.0, a
> >> list-shaped Nothing [], a dict-shaped Nothing {}, an int-shaped Nothing
> >> 0, a singleton Nothing None, and so forth.
>
> > The sound of that metaphor is rather pleasing ('sweet nothings'), but
> > I'm not so sure that metaphors belong in computer science and
> > programming.
>
> Programming models the world, it isn't the world. Every model is a
> metaphor. You can't get away from metaphors in programming, you can only
> hide them and pretend they aren't there.

I was not aware that the intended use for 'True' was 'Something'.  I
thought it merely signified membership in a predicate or relation.
'GreaterThan( 3, 2 )', so '3> 2== True'.  You might argue that numbers
are metaphors for the world, since they are external to causality,
have no temperature, etc., and likewise with logical predicates.  But
just because True is one metaphor, doesn't mean it is every metaphor.
Is casting to a boolean a metaphor for a metaphor?

Mathematically, 'bool' injects mathematical objects into the set
{ True, False }.  I would say it's a stretch to say that the empty
list maps to the True value, and non-empty lists map to the False
value.  Mathematically, there's no reason to choose that mapping as
the natural meaning and definition over any other, say 'list( x ) iff
len( list( x ) )% 2'.  (Some shells, I understand, suppose that there
are multiple ways to fail, while others suppose that there are
multiple ways to succeed.)  In programming practice, there is a
frequent division between empty lists and non-empty lists, so the
author chose to map one case to one value, and the other case to the
other.

> > Nothing can't have many shapes.
>
> In computing, you can't have a literal "nothing", because EVERYTHING
> needs to be stored as a pattern of bits.

Correct... until memory gates can self-destruct.  <cackle>

> In practice, for most high-level
> languages, those bits are interpreted as a type as well as a value, so
> the same bit pattern can mean different things according to what type it
> is expected to be. Alternatively, the same information can be represented
> in different bit patterns depending on how you interpret those bit
> patterns.
>
> So in the context of computer programming, of course you can have nothing
> with many "shapes": you have the number 0 represented as a single byte, a
> 16-bit integer, a 32-bit integer, a long-int or BigNum, a pointer with
> address 0, fixed point decimals of various sizes, Binary Coded Decimal, a
> rational, a single float 0.0, a double float 0.0, a string of "tally
> marks" without any tally, and so on, all of them in big-endian and little-
> endian formats.
>
> > Having no onions is the same as having no carrots.
>
> "If you have one onion and I take it away, how many onions do you have
> left?"
>
> If you answered "no carrots", I'd consider that a bizarre and unhelpful
> answer, and wonder what you possibly thought carrots had to do with my
> question.
>
> "Nothing" is not an absolute. "There is no wind" is not the same thing as
> "there is no money left in my bank account".
>
> > If the different shapes of nothing don't
> > compare equal to each other, which they don't, then they aren't all the
> > same thing in different shapes.
>
> Who said they were the same thing?

The fact that bool( [] ) == bool( {} ).  Merely that 'f( x )== f( y )'
does not imply that 'x== y'.  I am not arguing that '[]== {}', and I'm
pretty sure you aren't either.  However, x and y do form an
equivalence class under 'f', IIRC.

If you ask of (blank), 'Is there anything?', which is what you state
the 'bool' function means to do, there are only two answers: 'Yes,
there is something', and 'No, there is nothing'.

> > Furthermore, it is awfully presumptuous to give objects a default
> > 'nothing-ness' of 'something'.  If anything, they should be nothing by
> > default.  
>
> That's a stupid idea.
[argument] snip

Fine, withdrawn.  They shouldn't have one.

> > Conversion to other primitives is very picky; why should
> > Boolean be so tolerant?
>
> Because it is useful and meaningful to ask whether an arbitrary object
> represents something or nothing, but it's not useful or meaningful to ask
> what integer is equivalent to an arbitrary object.

It's more common for it to make sense to divide a set into two pieces
than it is to divide it into N pieces, the cardinality of the
integers.  But that doesn't make the presumed implementation 'return
True' for an entire type.

I think the closest you could come would be to try the '__len__'
method, and raise an exception if there isn't one.  But if '__len__'
is defined, then there is also a mapping from the type into the
integers.  By your logic, 'int( object )' should default to '__len__'
as well, since the mapping is defined!

The 'bool' function means to ask, 'What Boolean value is this object
most like?'.  The object's type should ascertain something about the
object, and answer.  But that is not what happens.  Python's
implementation ignores the object completely, and answers blindly.