On Sun, 05 Jul 2009 03:08:16 -0700, Paul Rubin wrote: > Steven D'Aprano <st...@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 -- http://mail.python.org/mailman/listinfo/python-list
