question of style

[Steven D'Aprano]

On Sun, 05 Jul 2009 03:08:16 -0700, Paul Rubin wrote:

> Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
>> > 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, 

Is your Google broken? *wink*

http://en.wikipedia.org/wiki/Furphy


> but I don't accept that "somethingness"
> vs. "nothingness" is the same distinction as truth vs falsehood.

It's the distinction used by Python since the dawn of time. Python only 
grew a bool type a few versions back.


> True
> and False are values in a specific datatype (namely bool), not abstract
> qualities of arbitrary data structures.  

I'm not talking about the constants True and False (nouns), but about 
true and false values (adjectives).


> 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 

There's nothing bogus about it.

Some languages such as Pascal and Java require a special Boolean type for 
if-branches. Other languages, like Forth, C, Lisp and Ruby do not.

http://en.wikipedia.org/wiki/Boolean_data_type


> and has been an endless source of bugs in Python code.


I wonder why these "endless" bugs weren't important enough to be 
mentioned in the rationale to PEP 285:

http://www.python.org/dev/peps/pep-0285/

You'd think something as vital as "if x Considered Harmful" would have 
made it into the PEP, but no. Instead Guido *explicitly* stated that he 
had no intention of forcing `if` to require a bool, describing `if x` as 
the "correct form" and calling scrapping such a feature as "crippling the 
language".

 
> Look how much confusion it causes here in the newsgroup all the time.

The only confusion is that you're causing me. Would you care to link to 
some?



>> "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.

And if they were the only types possible in Python, that might be 
relevant.


> I
> could see some value to having a generic "is_empty" predicate on
> containers though, to deal with this situation.

We have that already. It's spelled __bool__ or __nonzero__, and it 
applies to any object, not just containers.


> Your iterable could
> support that predicate.  In fact maybe all iterables should support that
> predicate.  They don't (and can't) all support "len".

Iterators are a special case, because in general they can't tell if 
they're exhausted until they try to yield a value.


>> 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.

Again with these alleged bugs.



-- 
Steven