On Wed, 2011-02-09 at 06:51 -0800, rantingrick wrote: > On Feb 9, 1:08 am, Paul Rudin <paul.nos...@rudin.co.uk> wrote: > > Nanderson <mandersonrandersonander...@gmail.com> writes: > > > loop would be infinite. I get what is happening in the function, and I > > > understand why this would work, but for some reason it's confusing me > > > as to how it is exiting the loop after a certain number of times. Help > > > is appreciated, thanks. > > > > It works because 0 tests false and because integer division yields > > integers... eventually you'll get something like 1/10 giving 0. > > It works because of a design flaw in the language! Specifically i am > referring to treating the integer 0 as False and any other integers as > True. There is also the empty vs non empty containers that work this > way besides numeric types. > > ---------------------------------- > Python 3.1.1 Interactive Session > ---------------------------------- > >>> bool(0) > False > >>> bool(1) > True > >>> bool(-1) > True > >>> bool(-1.0) > True > >>> bool(1.0) > True > >>> bool(0.0) > False > >>> bool([]) > False > >>> bool([1]) > True > > Sure it *seems* like a "bright" idea at first however later you find > out this sort of laziness just induces more subtle bugs in code. > Python3000 fixed a lot of warts in Python2.x HOWEVER, python3000 did > not go near far enough! We need more radical changes (and when i say > radical i mean removing poorly thought out design patterns like this > "boolean emulation"!) to the language before python will be a truly > 21st century language. > > We should have never written code like this... > > ------------ > Example 1: > ------------ > # lst = [] > > if lst: > blah > if not lst: > blah > > Example 1 is not explicit enough. Too much guessing is required by the > reader! > > ----------- > Example 2 > ----------- > if lst.lengh > 0: > blah > if not lst.empty(): > blah > if not empty(lst): > blah > > Example 2 is just explicit enough so that the reader knows *exactly* > what is happening! We don't want to be redundantly explicit, however > we sure as *hell* don't want to be implicit! Hmm, believe i read that > somewhere once... import this! > > The point is NEVER use an integer in place of a boolean! And i am NOT > blaming the OP here, no! I am blaming who ever came up with this > idiotic "emulation of booleans" crap! And don't tell me... "Well C did > it first we were just following by example"... because you just make > yourself out to be even a bigger idiot! > > Here is another example of bad habits passed down from "on high". > > def is_foo(): > if something: > return 1 > return 0 > > Why the HELL are you retuning integers in an obviously boolean > function? Are you trying to win Pearl hacker of the year award? Please > folks, always remember... NEVER emulate booleans, always use True/ > False for boolean behaviors. > > def is_foo(): > if something: > return True > return False > > *school-bell*
Can you explain what you would define True and False as?
-- http://mail.python.org/mailman/listinfo/python-list