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
--
https://mail.python.org/mailman/listinfo/python-list
