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: Steven D'Aprano on 11 Jul 2010 20:02 On Sat, 10 Jul 2010 23:50:05 -0700, rantingrick wrote: > You do realize that > Python must build a tuple for ever conditional that uses this semantic? > This is more bad, bad, bad than integer bool-ing! 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"! This is bad coding style Stephen. No, premature optimization is bad coding. Building a tuple is extremely fast: $ python -m timeit "x = ()" 1000000 loops, best of 3: 0.316 usec per loop $ python -m timeit "x = False" 1000000 loops, best of 3: 0.36 usec per loop Testing is fast too: $ python -m timeit "x = (); 1 if x else 2" 1000000 loops, best of 3: 0.663 usec per loop $ python -m timeit "x = False; 1 if x else 2" 1000000 loops, best of 3: 0.969 usec per loop You've been around here long enough that you should know better. Stop wasting your time, and ours, ranting over the enormous cost of things that aren't costly at all. Come back when you have profiled your code and can prove that the cost of building empty tuples is an actual bottleneck. -- Steven
From: Mark Lawrence on 11 Jul 2010 20:18 On 12/07/2010 01:02, Steven D'Aprano wrote: > On Sat, 10 Jul 2010 23:50:05 -0700, rantingrick wrote: > >> You do realize that >> Python must build a tuple for ever conditional that uses this semantic? >> This is more bad, bad, bad than integer bool-ing! 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"! This is bad coding style Stephen. > > No, premature optimization is bad coding. > > Building a tuple is extremely fast: > > $ python -m timeit "x = ()" > 1000000 loops, best of 3: 0.316 usec per loop > $ python -m timeit "x = False" > 1000000 loops, best of 3: 0.36 usec per loop > > > Testing is fast too: > > $ python -m timeit "x = (); 1 if x else 2" > 1000000 loops, best of 3: 0.663 usec per loop > $ python -m timeit "x = False; 1 if x else 2" > 1000000 loops, best of 3: 0.969 usec per loop > > > You've been around here long enough that you should know better. Stop > wasting your time, and ours, ranting over the enormous cost of things > that aren't costly at all. Come back when you have profiled your code and > can prove that the cost of building empty tuples is an actual bottleneck. > +1 Kindest regards. Mark Lawrence
From: Steven D'Aprano on 11 Jul 2010 20:23 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 IS NOT None. By this definition, the string "rantingrick hasn't thought this through" is an integer. It's not empty, and not None, so therefore an integer by your definition. Possibly the integer two-thirds of the way between 3 and 4. > Therefore the only logical way to handle > integer bool-ing is to say they are all True. For some definition of "logical". >> For bonus points, explain how you'd deal with any backwards >> compatibility problems that your fix introduces. > > We would't deal with backwards compatibility as this notion of bool(1) > == True and bool(0) == False if backwards way of thinking. Sure it saves > a few keystrokes but in the end only serves to obfuscate the code and > promote bad programming styles. WE SHOULD NEVER BE USING 1 IN PLACE OF > True AND 0 IN PLACE OF False! 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. So if your plan is to refuse to deal with existing code, I am very glad indeed that your plan will go absolutely nowhere. >> Have you considered forking Python? That may be the way forward here. > > I have considered this many times in the past and continue to > consider it even today. Please do. I think that this will be the best thing for the Python community. -- Steven
From: rantingrick on 11 Jul 2010 20:35 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. I NEVER said building EMPTY tuples was the cause of my rant. 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. The only reason i used the tuple was so that my conditional logic worked as expected. *Stephen* offered a solution in the form of using tuples within the conditional expression. I countered his solution by showing that creating tuples in a conditional expression is slower that testing for bool-inity. *Steven*, Please read the thread completely before making off hand comments else you could make a complete fool of yourself!
From: rantingrick on 11 Jul 2010 20:38
On Jul 11, 7:18 pm, Mark Lawrence <breamore...(a)yahoo.co.uk> wrote: > +1 Oh mark grow a spine already, really. I can't help but thinking of the spineless Robert Ford every time you open your mouth. |