PEP 285: Adding a bool type: yes, but not as int subtype

[Bengt Richter]

On 1 Apr 2002 21:52:17 GMT, bokr at oz.net (Bengt Richter) wrote:
[...a post to which Kris replied...]

Unfortunately my newsfeed cycles too damn fast, so I have to reply to Kris
by replying to myself, after reading from the archive and pasting as quoted
from there:

>Kris J. Zaragoza kzaragoza at attbi.com 
>Mon, 01 Apr 2002 22:38:39 GMT 

>In article <a8akqh$8bk$0 at 216.39.172.122>, Bengt Richter wrote:
>> Of course the 'hidden property' is only rhetoric here, but why not
>> make this a clear and controllable unified mechanism instead of a
>> collection of special effects? I would like to see an overridable
>> __bool__ method (not actually a programmatic property) for the base
>> object class, perhaps making deprecation of __nonzero__ possible.

>Now this is an idea with some merit.  I can see some real advantages
>to being able to define the truth value of a given object, or at least
>control its conversion to a bool.  But then, Guido's PEP already shows
>this as possible when creating a bool.  If you look at the __new__()
>constructor, it checks the truth value of the object when deciding
>which global value to return.  If this is how things are implemented
>in the C code (and I haven't checked), then __nonzero__() (or
>__len__()) is called if defined.  This gives us the control we're
>looking for.

Well, I wouldn't want to mess with __len__ if I e.g., were subtyping str
for something where I wanted to be able to write

    if s: print '"%s" (length %d) is special.' % (s, len(s))

I.e., in a logical context( if x..., x and ..., etc.), I think x.__bool__()
should have priority over x.__nonzero__() or x.__len__().

>> Well, what do you think of the above?

>It certainly clarifies matters a bit, but I still have to wonder
>whether it's worth the effort.  The way I see it, the mechanism for
>the customizations you describe is already present, albeit badly
>named.
I'm suggesting there may be cases where e.g., __len__() should still
function to control the range of an iteration, but __bool__() might
exist at the same time to signify some other condition.

>I certainly don't object to implementing the bool type.  I guess I
>just don't see it as a significant advantage.

I'd like the semantic clarity. And I'd like to define a class or subtype whose
boolean logical value doesn't depend on anyones concept of Nothing or Empty
if those don't fit. How about has-converged as a boolean meaning associated
with some object in a worker thread? Do I have to say the status is
empty of convergedness? Or that is has non-zero convergence?

Say I don't want a measure, I just want to know if the data is ready to use
when I poll. Or take a whimsical example: What if I want to subclass int and
be able to say if n: print n,'is a prime', expecting that n.__bool__()
will be called so I can calculate primeness and cache the result in a
boolean attribute for faster return next time, etc.

The point is to have freedom to use a useful general mechanism without
semantic contortions, or giving up the ability if __nonzero__ and/or __len__
already have uses for the class.

Regards,
Bengt Richter