On Wed, 11 May 2011 10:02:42 +0100, Hans Georg Schaathun wrote:
> The problem with 'if x' is that it requires a much more detailed
> understanding of python.
"Much" more detailed? Hardly.
Understanding that Python accepts any and all objects in truth-testing
concepts, and the rules thereof, is Python 101 territory. It's beginner-
level knowledge. It is far less advanced than the knowledge that ** is
used for exponentiation. After all, many programmers have never needed to
raise a number to a power, and might not learn about it for years, but
every programmer writes if or while statements at some point.
Not knowing that you can write "if x" instead of "if x == []" is like not
knowing that you can write
elif condition
instead of
else:
if condition
If somebody were to argue that it is "better to write else if explicitly,
instead of the confusing elif", we'd all laugh at them.
Every time the question of conditional testing comes up here, it never
ceases to astonish me how many developers argue against learning the
idioms of the language, and prefer to re-use the idioms of other
languages in Python.
Python is an object-oriented language where objects get to decide for
themselves whether they should be treated as true or false. Writing:
if x == []:
instead of
if x:
merely[1] because you worry that it isn't explicit enough, or could
confuse other developers, or out of some nagging concern that maybe
Python will do the wrong thing[2] unless you hold its hand through the
process, is as silly as writing this:
count = 0
for item in x:
count += 1
instead of:
count = len(x)
(As silly, but not as verbose.)
I don't mean to insult anyone, but I've heard and read all the arguments
against Python's truth-testing, and they don't impress me in the
slightest. Most of them strike me as silly. The only argument that
carries any weight to me is one which I haven't seen anyone raise:
"if x:" turns something which arguably could have been a mistake ("oops,
I forgot to write the condition!") into valid code.
[1] It may be that there are good, solid reasons for writing explicit
len(x)==0 tests, although I'm hard-pressed to think of any. The closest I
come to is when you wish to emphasize "equal to some number that just
happens to be zero" rather than "it's a false/empty value". If so, you
get a free pass to write the test the long way. E.g. you might write
"x % 2 == 1" rather than just "x % 2" because you want to highlight that
the remainder equals one, rather than the remainder merely being a true
value.
[2] Of course, a custom object x might misbehave when you test it for
truth value. That would be a bug, just like it would be a bug if it
misbehaved when you call len(x) == 0. If you can't trust "if x" to work,
what makes you think you can trust "len(x) == 0" either?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
