integer >= 1 == True and integer.0 == False is bad, bad, bad!!!
in [Python]
|
Prev: grailbrowser now running under python 2.5 (probably above too)
Next: Naming Conventions, Where's the Convention Waldo?
From: Paul Rubin on 12 Jul 2010 23:58 Steven D'Aprano <steve-REMOVE-THIS(a)cybersource.com.au> writes: > What Python does instead is to accept *any* object in a context where > other languages (such as Pascal) would insist on a boolean. 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.
From: Steven D'Aprano on 13 Jul 2010 00:52 On Mon, 12 Jul 2010 20:58:39 -0700, Paul Rubin wrote: > Steven D'Aprano <steve-REMOVE-THIS(a)cybersource.com.au> writes: >> What Python does instead is to accept *any* object in a context where >> other languages (such as Pascal) would insist on a boolean. > > 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. -- Steven
From: Michael Torrie on 13 Jul 2010 01:28 On 07/12/2010 06:18 PM, Steven D'Aprano wrote: > 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.
From: Michael Torrie on 13 Jul 2010 01:31 On 07/12/2010 06:36 PM, Paul Rubin wrote: > 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.
From: Jean-Michel Pichavant on 13 Jul 2010 07:24
Steven D'Aprano wrote: > On Mon, 12 Jul 2010 19:28:28 -0600, Ian Kelly wrote: > > >> On Mon, Jul 12, 2010 at 6:18 PM, Steven D'Aprano >> <steve(a)remove-this-cybersource.com.au> wrote: >> >>>> I prefere to explicitly write what I want to test: >>>> >>>> if myInt <> 0: >>>> >>> I would argue against that. Why do you, the coder, care about the >>> specific details of treating ints in a boolean context? The int type >>> itself knows, leave the decision to it. >>> >> I think you're missing the point. He's not using ints in a boolean >> context. If it were a boolean context, he would be using bools in the >> first place. >> > > 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) |