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: Stephen Hansen on 11 Jul 2010 01:51 On 7/10/10 10:38 PM, rantingrick wrote: > Seems kinda dumb to build a tuple just so a conditional wont blow > chunks! This integer bool-ing need to be fixed right away! Yes, let us penalize the thousands of use cases where 0 being false is useful and good, for the benefit of the one use-case (indexing) where it is not. You don't need to build a tuple. Just change the tests, to "if choiceIdx1 is not None". Its a little more work, sure. But its not enough that its even vaguely worth breaking the otherwise very useful behavior of bool(0) == False. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: rantingrick on 11 Jul 2010 02:03 On Jul 11, 12:51 am, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > You don't need to build a tuple. Just change the tests, to "if > choiceIdx1 is not None". Its a little more work, sure. But its not > enough that its even vaguely worth breaking the otherwise very useful > behavior of bool(0) == False. Hmm, i beg to differ. The if choice1 is not None and choice2 is not None is going to run off my screen and into my neighbors backyard swimming pool! If you *can* Stefen, show the class a "very useful" case for integer bool-ing? Please do so, although i doubt you can offer one. Maybe you'll offer this kinda kludgy stuff... function(option=1) #instead of True function(option=0) #instead of False This is another example of the damage integer booling does to your code and your mind. What happened to explicit is better than implicit? What happened to tim toady is a SOB! It is easy to get drawn into this way of coding and very hard to pull out. And it's wrong, wrong, wrong. NEVER substitute 1 for True and/or 0 for False! NEVER! This is anti Pythonic! py> import this
From: Stephen Hansen on 11 Jul 2010 02:22 On 7/10/10 11:03 PM, rantingrick wrote: > On Jul 11, 12:51 am, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > >> You don't need to build a tuple. Just change the tests, to "if >> choiceIdx1 is not None". Its a little more work, sure. But its not >> enough that its even vaguely worth breaking the otherwise very useful >> behavior of bool(0) == False. > > > Hmm, i beg to differ. The if choice1 is not None and choice2 is not > None is going to run off my screen and into my neighbors backyard > swimming pool! "if choiceIdx1 is not None and choiceIdx2 is not None:" is 54 characters. Your straw man argument fails. Even if this is in a method of a class, that's only 64; even with another two levels of indentation it still isn't longer then the 80 which is where some people consider things "long" (I do not: I don't mind code > 100). If you are so desperately concerned with space, then simply do: if (choiceIdx1, choiceIdx2) != (None, None): Its only eleven characters longer. Or, you can do: if None not in (choiceIdx1, choiceIdx2): Its only two characters. You really can't honestly be making an argument about two characters. > If you *can* Stefen, My name is Stephen. This is the second time you've done this: if you can't show even the vaguest respect and actually use my name and not a mockery of it, then I'll just killfile you. > show the class a "very useful" case for integer > bool-ing? Please do so, although i doubt you can offer one. Maybe > you'll offer this kinda kludgy stuff... > > function(option=1) #instead of True > function(option=0) #instead of False Of course I won't offer that. If I wish a boolean flag, something which can have only one of two states (although sometimes a three-state 'maybe' is useful, with None being the 'neither true nor false'), I'd use the boolean. There's numerous cases where "if x" where x is an integer is useful. A counter is the simplest example. Say you're counting how many watermelons are in your inventory there is, and you want to test if there's any or not. "if watermelons" is the concise, readable, understandable way to express this. Readability counts. A boolean test in Python tests "something" verses "nothing", it doesn't test Truth verses False It is entirely consistent in this regard (except in the case of custom classes which may decide to do strange things). Zero is, clearly, nothing. > This is another example of the damage integer booling does to your > code and your mind. Utter nonsense. No one does that unless they are coming from C or some other language without a True/False and don't know about it, or if they are using a codebase which is supporting a very old version of Python before True or False were introduced. But you're just going to argue endlessly, no doubt. Have you ever actually considered the fact that your gut reaction might, I don't know, be wrong or misguided? I've admitted when I'm wrong on more then one occasion. I really don't know why I bother. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Ian Kelly on 11 Jul 2010 02:57 On Sun, Jul 11, 2010 at 12:03 AM, rantingrick <rantingrick(a)gmail.com> wrote: > This is another example of the damage integer booling does to your > code and your mind. What happened to explicit is better than implicit? Explicit is better than implicit. Hence, if you're specifically testing for the property of not being None rather than for the more general truth value, it's better to write "if choiceIdx1 is not None" rather than just "if choiceIdx". This holds true for empty collections as well. On Sun, Jul 11, 2010 at 12:22 AM, Stephen Hansen <me+list/python(a)ixokai.io> wrote: > There's numerous cases where "if x" where x is an integer is useful. A > counter is the simplest example. Say you're counting how many > watermelons are in your inventory there is, and you want to test if > there's any or not. "if watermelons" is the concise, readable, > understandable way to express this. Readability counts. I would also point out that the current semantics mean that "bool(container)", "bool(len(container))", and "len(container) > 0" are all equivalent. I view this as a positive thing. It also means that "if integer" in Python and "if (the_same_integer)" in a C module have the same semantics. It would be a nasty surprise for writers of C modules if they didn't. And I think that partly this is simply historical. Before a proper boolean type was added to Python, 1 and 0 were the norm for storing truth values. Changing the truth value of 0 when bools were introduced would have broken tons of existing code. This is also the reason why bool is a subclass of int.
From: Ian Kelly on 11 Jul 2010 03:11
On Sun, Jul 11, 2010 at 12:57 AM, Ian Kelly <ian.g.kelly(a)gmail.com> wrote: > And I think that partly this is simply historical. Before a proper > boolean type was added to Python, 1 and 0 were the norm for storing > truth values. Changing the truth value of 0 when bools were > introduced would have broken tons of existing code. This is also the > reason why bool is a subclass of int. Another thought related to that list bit: if bool(0) were True, then bool(int(False)) would also be True. That seems messed up. Then again, bool(str(False)) is already True. Does that bother anybody other than me? |