question of style

[Lie Ryan]

Paul Rubin wrote:
> Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
>> "if len(x) == 0" is wasteful. Perhaps I've passed you a list-like 
>> iterable instead of a list, and calculating the actual length is O(N). 
> 
> That doesn't happen in any of Python's built-in container types.  I
> could see some value to having a generic "is_empty" predicate on
> containers though, to deal with this situation.  Your iterable could
> support that predicate.  In fact maybe all iterables should support
> that predicate.  They don't (and can't) all support "len".

That doesn't happen because all python's built-in container keep track
of its own length and are able to quickly determine its own length. But
outside builtins, certain iterables cannot determine its own length
quickly, e.g. iterators, but may have alternative ways to determine
whether itself is empty (through a "private" attributes). If you peek
through this private attribute, you're breaking encapsulation. Although
python is a language of consenting adults and doesn't really have a real
private, codes that breaks encapsulation is prone to bugs.

>>> Yes, it saves a few keystrokes to say "if x:" instead of "if
>>> len(x)==0:" or even "if bool(x):",
>> It's not about saving keystrokes -- that's a furphy. It's about
>> encapsulation. Objects are in a better position to recognise when
>> they are "something" (true) or "nothing" (false) than you are.
>
> I don't know what a furphy is, but I don't accept that "somethingness"
> vs. "nothingness" is the same distinction as truth vs falsehood.  True
> and False are values in a specific datatype (namely bool), not
> abstract qualities of arbitrary data structures.  The idea that the
> "if" statement selects between "somethingness" and "nothingness"
> rather than between True and False is a bogus re-imagining of the
> traditional function of an "if" statement and has been an endless
> source of bugs in Python code.  Look how much confusion it causes here
> in the newsgroup all the time.

Neither python's `if` nor `if` in formal logic is about testing True vs.
False. `if` in python and formal logic receives a statement. The
statement must be evaluatable to True or False, but does not have to be
True or False themselves. It just happens that True evaluates to True
and False evaluates to False. For example, the statement:

P := `e = 2.7182818284590451`
Q := `e = m*c**2`
----------------------------------
P -> Q

P -> Q evaluates to:
`e = 2.7182818284590451` -> `e = m*c**2`

Note that `e = 2.7182818284590451` is a statement, not a boolean value.
The truth value of `e = 2.7182818284590451` is determined by "calling"
(note the double quotes) `e = 2.7182818284590451`.statement_is_true(),
which when written in python syntax becomes: (e ==
2.7182818284590451).__bool__()

>> If you write len(x)==0 Python doesn't complain if x is a dict
>> instead of the list you were expecting. Why is it acceptable to
>> duck-type len(x) but not truth-testing?
> 
> I haven't seen the amount of bugs coming from generic "len" as from
> something-vs-nothing confusion.