Expression can be simplified on list

[Terry Reedy]

On 9/29/2016 2:47 AM, Rustom Mody wrote:
> On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote:
>> On 9/14/2016 3:16 AM, Rustom Mody wrote:
>>
>>> In THOSE TYPES that element can justifiably serve as a falsey (empty) type
>>>
>>> However to extrapolate from here and believe that ALL TYPES can have a falsey
>>> value meaningfully, especially in some obvious fashion, is mathematically nonsense.

There is no end to possible nonsensical extrapolations.  I presume you 
had a reason to point out this one.

>> Python make no such nonsense claim.  By default, Python objects are truthy.
>>
>>  >>> bool(object())
>> True
>>
>> Because True is the default, object need not and at least in CPython
>> does not have a __bool__ (or __len__) method.  Classes with no falsey
>> objects, such as functions, generators, and codes, need not do anything
>> either.  In the absence of an override function, the internal bool code
>> returns True.
>>
> Not sure what you are trying to say Terry...

I reported how CPython's bool works, after doing some experiments.

> Your English suggests you disagree with me

I disagree with a possible implication of your statement, that Python 
bools are based on a nonsensical belief.  It does not matter much to 
what I said whether you intended that implication or not.

> Your example is exactly what I am saying; if a type has a behavior in which
> all values are always True (true-ish) its a rather strange kind of bool-nature.

Your conclusion from the examples is slightly different from mine.

>> It is up to particular classes to override that default and say that it
>> has one or more Falsey objects.  They do so by defining a __bool__
>> method that returns False for the falsey objects (and True otherwise) or
>> by defining a __len__ method that returns int 0 for falsey objects (and
>> non-0 ints otherwise).  If a class defines both, __bool__ wins.

More reporting on how CPython works, based on experiments.  For the last 
statement, I tried giving a class contradictory methods.

> Sure one can always (ok usually) avoid a bug in a system by not using the
> feature that calls up the bug. Are you suggesting that that makes the bug non-exist?

By 'bug', you here mean 'design bug', as opposed to 'implementation 
bug'.  Design bugs are in the eyes of beholders.  Here, we behold 
differently.

Logic is about binary predicates/partitions/decisions.  Bool allows a 
class to define a default partition for use in conditional expressions 
by defining a __bool__ method.

> In more detail:
> - If user/programmer defines a new type
> - Which has no dunder bool
> - Which has no dunder len

A subclass of such a class might add either of those methods.  Indeed, 
'object' is such a class and *some* subclasse* do add one or the other.

Or, with duck-typing, the class might part of a function domain that 
does include partitioned classes.

> - And then uses a value of that type in a non-trivial bool-consuming position
> such as the condition of an if/while etc
>
> There's a very good chance that bool-usage is buggy

I agree that 'if self' when self is essentially guaranteed to be truthy 
is bad coding.  Redundant or dead code may be a bad idea, but is not 
buggy in itself in the usual sense.

> Why not default it in the way that AttributeError/NameError/TypeError etc
> are raised?

Try - except and exceptions are an alternate flow system that partition 
the behavior of functions + arguments.  It would be annoying to mix the 
two and require (most) every if and while statement to be embedded in 
try - except.

-- 
Terry Jan Reedy