integer >= 1 == True and integer.0 == False is bad, bad, bad!!!

S

Steven D'Aprano

I'm aware of what Python does, just saying I can sympathize with the
sentiment that explicit conversions would make more sense. I wouldn't
change it in Python since it's what we're all used to, but if I were
designing a language from scratch I'd probably make it explicit.

Fair enough, and that's a reasonable design choice too. Ruby, for
example, only has two false values: False and Null.
 
M

Michael Torrie

Early versions of BASIC used -1 as true and 0 as false.

They did this for good reason. BASIC had no logical operators. AND,
OR, and NOT were all actually bitwise operators. By making the True
value -1, the bitwise operations yielded the result one would expect
from logical operations.
 
M

Michael Torrie

I'd personally prefer

if not bool(myValue):

which would call the myValue's __bool__ method if it chose to implement
one. Explicit is better than implicit.

That's just ugly. Probably a more explicit way would be to have an
is_true() and is_false() function/method. if is_false(my_value).

But that's ugly too, especially when the idea of emptiness or falseness
is so consistently defined across python types. I have yet to encounter
any situation where I got tripped up on such a small thing as the OP.
 
J

Jean-Michel Pichavant

Steven said:
Of course he is -- he's branching on an int (a boolean context), and
explicitly writing out the test as myInt <> 0. In fact, that test could
just as easily be written as bool(myInt), which has the benefit of being
even more explicit that you want a bool.

I never use integers as boolean value. There is no need to in python,
since True and False are available. I use integers only as integers
(hope you see what i mean, i.e to count a number of...).
Knowing that, the only meaning possible would be

if myInt:

equals to

if myInt is not None:

in other words, if myInt is a meaningful integer.

But this is wrong in python, as "if myInt" means "if myInt <>None and
myInt <>0" (I experienced bug because of my wrong understanding).
Fine I can live with that. It forces me to write explicitly the
condition I require, which is a good thing (explicit >> implicit).

JM

PS : you made a typo, myInt <> 0 does not equal to bool(myInt) (when
myInt is None)
 
P

Peter Pearson

On 13 Jul 2010 03:16:31 GMT, Steven D'Aprano wrote:
[snip]
. . . and we rightly shake our heads at the sheer
n00b-ness of it. Writing the explicit tests:

if bool(myInt):

or even:

if myInt <> 0:

are firmly in the same category. The only difference is that it is more
familiar and therefore comfortable to those who are used to languages
that don't have Python's truth-testing rules.

I have been a Python newbie for over 10 years, and would like
to mention that what's clear to Python experts is much less clear
to me. I think this might matter more than you think, since
clarity-to-the-semicompetent is an important component of
the "activation barrier" that heavily influences market share.

Names are seldom so felicitous as myInt. In practice, when
trying to read foreign code, I encounter "if x:", and poor
commenting leaves me ignorant of x's type and thus of the
exact meaning of "if x:". When I see "if x <> 0:", I get
the feeling that x is some kind of number, and the meaning
of the test is pretty clear.

And then when writing code, I usually can't confidently
retrieve the recipe for the boolean interpretation of x from
readily accessible memory, so I will write explicitly what I
mean, and thereby do a favor for the next guy to look at the
code, who is almost always a 10-year Python newbie who needs
all the clues he can get.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top