question of style
steve at REMOVE-THIS-cybersource.com.au
Sun Jul 5 18:00:03 CEST 2009
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*
> 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.
> 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.
> 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:
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
> 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
>> "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
> 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.
More information about the Python-list