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 21:33 On 7/11/10 5:51 PM, rantingrick wrote: > On Jul 11, 7:23 pm, Steven D'Aprano <st...(a)REMOVE-THIS- > cybersource.com.au> wrote: >> On Sun, 11 Jul 2010 16:22:41 -0700, rantingrick wrote: >>> On Jul 11, 1:19 pm, Mark Dickinson <dicki...(a)gmail.com> wrote: >> >>>> Okay. What fix do you propose? Would your fix maintain the identity >>>> "0 == False"? >> >>> No because all integers should bool True. An integer is a value that IS >>> NOT empty >> >> Integers aren't containers, the concept of "empty" or "full" doesn't >> apply to them. > > And again you failed to follow along with the thread so you have no > idea where my statements is projected from. Of course integers are NOT > containers in the way a list or dict is a container! My remark was a > rebuff of comments made by Stephen earlier. I forgot to reply to that; an integer is certainly not empty. But 0 is nothing. Its not empty vs full. Its nothing vs something that determines if something is considered true-ish or not. >> Nevertheless, what is done is done, and now you have to deal with it. >> Just wishing that it was never done is not dealing with backwards >> compatibility, and breaking existing code is not an acceptable option. > > Yea and if Guido would have taking your defeatist attitude we'd all be > using braces for scope! Guido made a new language. You should go do that. Feel free to define it however you want. In Python, the meaning of "truth" goes back a very, very, very long way. It isn't going to change. Every once in awhile people hate it. For awhile after True/False were introduced, some people wanted to go modify things to a boolean strictness. But in the end, its all pointless. This is just how it works. Its not going to change. It would break thousands and thousands of lines of code. There's not going to be another major breakage for, oh, maybe ten years. Or twenty. If ever. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Brendon Wickham on 11 Jul 2010 21:41 "i had once considered you one of the foremost intelligent minds within this group. However, after your display within this thread i am beginning to doubt my original beliefs of you." "Oh ... grow a spine already, really. I can't help but thinking of the spineless Robert Ford every time you open your mouth" @rantingrick : these comments among others fail to meet the standard of engagement expected of, and traditional to, this list. Take a breath, get some sleep and come back with a level head and a civil tongue. If you have any valid point to make at all, your attitude so far has failed to make it credible, and nor will it enable you to enlist supporters.
From: Steven D'Aprano on 11 Jul 2010 22:09 On Sun, 11 Jul 2010 17:35:18 -0700, rantingrick wrote: > On Jul 11, 7:02 pm, Steven D'Aprano <st...(a)REMOVE-THIS- > cybersource.com.au> wrote: > >> Come back when you have profiled your code and can prove that the cost >> of building empty tuples is an actual bottleneck. > > Did you even read this thread, i mean from head to tail. Yes I did. > I NEVER said > building EMPTY tuples was the cause of my rant. The cause of your rant appears to be that you have nothing better to do with your time. But the *excuse* for your rant was that you had to replace: choiceIdx1 = None with: choiceIdx1 = () and followed with: Seems kinda dumb to build a tuple just so a conditional wont blow chunks! and My bin packer could potentially compute millions of parts. I do not want to waste valuable processor cycles building numerous TUPLES just for the sake of a conditional "condition"! [emphasis added] > My complaint (an oddly > enough the title of this thread!) concerns the fact that Python treats 0 > as False and every integer above and below 0 as True. Which is another > example of how *some* aspects of Python support bad coding styles. Yes, Python does support bad coding styles. The treatment of 0 as a false value is not one of them though. -- Steven
From: Jean-Michel Pichavant on 12 Jul 2010 06:34 Steven D'Aprano wrote: >> My complaint (an oddly >> enough the title of this thread!) concerns the fact that Python treats 0 >> as False and every integer above and below 0 as True. Which is another >> example of how *some* aspects of Python support bad coding styles. >> > > Yes, Python does support bad coding styles. The treatment of 0 as a false > value is not one of them though. > > Well, actually some people might think otherwise. While I disagree with the OP flaming style, one could argue that muting an integer into a boolean makes no sense (I'm one of them). You can still do it, but there is no "right" way to do it. You can decide that everything else than 0 is True, but you could also pickup the integer 3 as false value, it would work as well since it makes no sense. This is just an arbitrary definition. Where the OP is fooling himself, is that you can't state that bool-ing an integer makes no sense and state the line after that 0 *should* | *has to* return True. I personally can live with 0 == False (with all due respect to our C-coding ancestors :) ), however as one of my personal coding rule I avoid using it. I prefere to explicitly write what I want to test: if myInt <> 0: or if myInt is not None: etc... That way I do not rely on a arbitrary int-to-bool mutation. JM
From: Steven D'Aprano on 12 Jul 2010 20:18
On Mon, 12 Jul 2010 12:34:46 +0200, Jean-Michel Pichavant wrote: > Well, actually some people might think otherwise. While I disagree with > the OP flaming style, one could argue that muting an integer into a > boolean makes no sense (I'm one of them). You can still do it, but there > is no "right" way to do it. > You can decide that everything else than 0 is True, but you could also > pickup the integer 3 as false value, it would work as well since it > makes no sense. This is just an arbitrary definition. Choosing 3 as a false value would be arbitrary, but the choice of 0 is anything but arbitrary. The distinction that Python makes is between values which are Something (true values) and those which are Nothing (false values). Python has an infinite number of ways of spelling Something: True, 1, 2, 3.1415, "abc", (2, 4), [None, 1, "A"], ... and a smaller number of ways of spelling Nothing: False, None, 0, 0.0, "", (), [], ... The fact that False == 0 (as opposed to, say, [] != 0) is due to the need for backwards compatibility. That bools are implemented as a subclass of int is a historical accident. The fundamental distinction in Python is between objects which are Something and those that are Nothing, and that's not an arbitrary distinction, it's a very deep distinction. This is why virtually all low-level languages treat 0 as a false flag and 1 (or sometimes -1) as a true flag. I say "virtually all", not because I know of any exceptions, but because in the history of computer languages you can probably find every design mistake, arbitrary choice, and perverse decision imaginable made by *somebody*. Consider branch statements. Forth jumps to the "true" branch on any integer flag, and to the "false" branch on 0, but the canonical true value is either 1 (0000 00001 in binary) or -1 (1111 1111). Early versions of BASIC used -1 as true and 0 as false. With Pascal's strong type-checking, you were forced to use the boolean type in branches, but (if I recall correctly) the language guaranteed that false was 0 and true was 1: a packed array of bools would use a 0 bit for false and 1 for true, and an unpacked array would use eight zero bits versus seven zeroes and an one. So there's historical precedent from other languages, backwards compatibility with early Python versions, and a fundamental philosophical distinction all in favour of using 0 for false. Not arbitrary at all. > 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. Sure, in the specific case of ints, the distinction is so fundamental, so basic, and so unlikely to change, that there's no real harm in the explicit test. But consider some other type: if myValue.count <= 0 and myValue.next is None and myValue.blob == "": # myValue is considered false versus: if not myValue: Which would you prefer? I think the choice is obvious: the type knows whether it is equivalent to true or false, leave it up to the object to decide. Why bother making an exception for ints, or strings? -- Steven |