Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38408 > unrolled thread

Re: Implicit conversion to boolean in if and while statements

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 21:53 -0800
    Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-08 17:15 +1100
    Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-08 18:22 +1100
      Re: Implicit conversion to boolean in if and while statements MRAB <python@mrabarnett.plus.com> - 2013-02-08 17:14 +0000
        Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-09 09:18 +1100
    Re: Implicit conversion to boolean in if and while statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-08 09:42 +0000

#38408 — Re: Implicit conversion to boolean in if and while statements

On Monday, July 16, 2012 8:45:51 PM UTC-5, rusi wrote:
> On Jul 15, 9:50 pm, Rick Johnson <rantingrickjohn...@gmail.com> wrote:

> > I think this issue is not so much a "bool test" vs "type
> > test", but more an ambiguous syntax issue.
> > 
> 
> If you know some English, its clear that if and while
> create bool contexts. 

Wrong. "if and "while" do not /create/ anything. On a syntactical level they merely /suggest/ to the reader that the following statement is expected to be a boolean value. It is the /statement/ itself that creates the boolean value, not the keywords! 

Observe:

    0 == 0 -> True
    isinstance("5", int) -> False
  
You see, "if" and "while" don't create anything, in reality they merely execute a block of code depending on the value of the statement that follows the keyword. "if" and "while" are only *logical switches* and nothing more. You could write a simple quasi-example of "if" as a function like this:

    def if_(value):
        if not value:
            return
        # do_something_here

  
Those previous statements where /explicit/, and as such need no bool() function to resolve their Boolean values, however, consider the following /implicit/ conversions to Boolean:

    [] -> False
    [1] -> True
    "" -> False
    "1" -> True
    0 -> False
    1 -> True
    2 -> True
    etc...
  
It is my strong opinion that these types of implicit conversions are evil obfuscations of the truth. If we want to convert an object to a Boolean, then use the bool() function on that object:

    bool([]) -> False
    bool([1]) -> True
    etc...
  
Heck! Why even have a damn bool function if you're never going to use it?
  
> [If you know English but have not
> studied logic the 'if/while' make sense whereas 'bool' is
> gobbledygook]

And which Univeristy would you recommend for studying the intricacies of "gobbledygook"? ;-)

[toc] | [next] | [standalone]

#38412

On Fri, Feb 8, 2013 at 4:53 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> And which Univeristy would you recommend for studying the intricacies of "gobbledygook"? ;-)

Dunno, where'd you get your degree in logic?

*dives for cover*

ChrisA

[toc] | [prev] | [next] | [standalone]

#38426

Rick Johnson wrote:

> Why even have a damn bool function if you're never going to use it?

bool is for converting arbitrary objects into a canonical True or False
flag. E.g. one use-case is if you wish to record in permanent storage a
flag, and don't want arbitrary (possibly expensive) objects to be recorded.

Most of the time, you shouldn't care whether you have a canonical True/False
bool, you should only care whether you have something which duck-types as a
boolean flag: a truthy or falsey value. In Python, all objects duck-type as
flags. The usual interpretation is whether the object represents something
or nothing:

"nothing", or falsey values: None, False, 0, 0.0, '', [], {}, set(), etc.
(essentially, the empty value for whichever type you are considering)

"something", or truthy values: True, 1, 2.5, 'hello world', etc.
(essentially, non-empty values).

Prior to Python 3, the special method __bool__ was spelled __nonempty__,
which demonstrates Python's philosophy towards duck-typing bools.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#38466

On 2013-02-08 07:22, Steven D'Aprano wrote:
> Rick Johnson wrote:
>
>> Why even have a damn bool function if you're never going to use it?
>
> bool is for converting arbitrary objects into a canonical True or False
> flag. E.g. one use-case is if you wish to record in permanent storage a
> flag, and don't want arbitrary (possibly expensive) objects to be recorded.
>
> Most of the time, you shouldn't care whether you have a canonical True/False
> bool, you should only care whether you have something which duck-types as a
> boolean flag: a truthy or falsey value. In Python, all objects duck-type as
> flags. The usual interpretation is whether the object represents something
> or nothing:
>
> "nothing", or falsey values: None, False, 0, 0.0, '', [], {}, set(), etc.
> (essentially, the empty value for whichever type you are considering)
>
> "something", or truthy values: True, 1, 2.5, 'hello world', etc.
> (essentially, non-empty values).
>
Anything that's not falsey is truey.

> Prior to Python 3, the special method __bool__ was spelled __nonempty__,
> which demonstrates Python's philosophy towards duck-typing bools.
>
Incorrect, it was spelled __nonzero__.

[toc] | [prev] | [next] | [standalone]

#38478

MRAB wrote:

> On 2013-02-08 07:22, Steven D'Aprano wrote:

>> Prior to Python 3, the special method __bool__ was spelled __nonempty__,
>> which demonstrates Python's philosophy towards duck-typing bools.
>>
> Incorrect, it was spelled __nonzero__.

Oops, so it was. Sorry for the brain-fart.

__nonzero__ or not, nevertheless the implication still applies: all types
are meant to map to "nothing" (zero) or "not nothing" (non-zero).



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#38435

On 08/02/2013 06:15, Chris Angelico wrote:
> On Fri, Feb 8, 2013 at 4:53 PM, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
>> And which Univeristy would you recommend for studying the intricacies of "gobbledygook"? ;-)
>
> Dunno, where'd you get your degree in logic?

 From the University of Wallamaloo whilst in charge of the sheep dip?

>
> *dives for cover*
>
> ChrisA
>
-- 
Cheers.

Mark Lawrence

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web