Expression can be simplified on list
Terry Reedy
tjreedy at udel.edu
Thu Sep 29 15:42:58 EDT 2016
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
More information about the Python-list
mailing list