Easy function, please help.

[Westley Martínez]

On Wed, 2011-02-09 at 06:51 -0800, rantingrick wrote:

> On Feb 9, 1:08 am, Paul Rudin <paul.nos... at rudin.co.uk> wrote:
> > Nanderson <mandersonrandersonander... at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110209/0e0f7e15/attachment-0001.html>