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

Operator Precedence/Boolean Logic

Started by	Elizabeth Weiss <cake240@gmail.com>
First post	2016-06-21 20:40 -0700
Last post	2016-06-22 20:43 +0100
Articles	20 on this page of 95 — 20 participants

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

  Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-21 20:40 -0700
    Re: Operator Precedence/Boolean Logic Ben Finney <ben+python@benfinney.id.au> - 2016-06-22 13:59 +1000
      Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:19 -0700
      Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:20 -0700
    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-22 16:02 +1000
    Re: Operator Precedence/Boolean Logic Christian Gollwitzer <auriocus@gmx.de> - 2016-06-22 08:26 +0200
      Re: Operator Precedence/Boolean Logic Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-22 10:14 +0300
        Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:21 -0700
    Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-22 00:42 -0700
      Re: Operator Precedence/Boolean Logic Larry Hudson <orgnut@yahoo.com> - 2016-06-22 20:12 -0700
        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-23 13:59 +1000
          Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:23 -0700
          Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 09:58 +0200
            Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 11:16 +0300
              Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-23 01:53 -0700
                Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:10 +0300
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 11:27 +0200
                    Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:53 +0300
                      Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 12:54 +0200
                        Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 13:59 +0300
                          Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 13:15 +0200
                            Re: Operator Precedence/Boolean Logic Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-23 15:05 +0300
                              Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-23 22:13 +1000
                  Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-23 02:44 -0700
                    Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:57 +0300
                      Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-24 22:38 -0700
                        Re: Operator Precedence/Boolean Logic Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-25 09:46 +0300
              Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 11:01 +0200
            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 19:39 +1000
              Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 12:21 +0200
                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-23 22:37 +1000
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 15:24 +0200
                  Re: Operator Precedence/Boolean Logic Random832 <random832@fastmail.com> - 2016-06-23 09:26 -0400
                    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-24 02:43 +1000
                  Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-24 01:49 +1000
          Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-25 11:56 +0300
        Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-22 21:47 -0700
          Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-22 22:00 -0700
          Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 08:34 +0200
            Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 09:46 +0300
            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 17:05 +1000
              Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 10:17 +0200
                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 18:48 +1000
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 11:23 +0200
                  Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-23 21:45 +1000
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 14:08 +0200
                  Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 14:22 +0200
              Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 10:23 +0200
              Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 10:32 +0200
                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 19:17 +1000
                  Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:46 +0300
                    Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 12:19 +0200
                    Re: Operator Precedence/Boolean Logic Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-26 11:01 +1200
                      Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-29 03:21 -0700
                        Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-29 21:06 +1000
                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-29 23:08 +1000
                          Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-29 06:30 -0700
                            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-30 09:40 +1000
                              Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-30 09:01 -0700
                                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-01 03:22 +1000
                                  Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-15 22:48 -0700
                                    Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-15 22:58 -0700
                                      Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-16 19:14 +1000
                                    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-16 20:16 +1000
                                      Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-16 20:46 +1000
                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-16 21:02 +1000
                                          Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 00:26 +1000
                                        Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 05:33 -0700
                                          Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 02:27 +1000
                                            Re: Operator Precedence/Boolean Logic MRAB <python@mrabarnett.plus.com> - 2016-07-16 17:58 +0100
                                              Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 20:43 -0700
                                                Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 14:05 +1000
                                                  Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 23:44 -0700
                                                    Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 23:59 -0700
                                                    Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 17:33 +1000
                                                      Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-17 00:44 -0700
                                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 20:04 +1000
                                                    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 21:02 +1000
                                                      Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-17 08:00 -0700
                                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-18 01:58 +1000
                                                          Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-18 02:01 +1000
                                            Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 03:06 +1000
                                      Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 05:15 -0700
                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 02:36 +1000
                          Re: Operator Precedence/Boolean Logic Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-29 15:00 +0000
                            Re: Operator Precedence/Boolean Logic Jon Ribbens <jon+usenet@unequivocal.eu> - 2016-06-29 15:05 +0000
                            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-30 09:44 +1000
                  Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 11:51 +0200
          Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 17:20 +1000
          Re: Operator Precedence/Boolean Logic Random832 <random832@fastmail.com> - 2016-06-23 09:18 -0400
        Re: Operator Precedence/Boolean Logic Christian Gollwitzer <auriocus@gmx.de> - 2016-06-23 09:11 +0200
      Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:22 -0700
    Fwd: Operator Precedence/Boolean Logic Jorge Gimeno <jlgimeno71@gmail.com> - 2016-06-21 20:56 -0700
    Re: Operator Precedence/Boolean Logic Random832 <random832@fastmail.com> - 2016-06-22 10:10 -0400
    Re: Operator Precedence/Boolean Logic Erik <python@lucidity.plus.com> - 2016-06-22 20:43 +0100

Page 1 of 5 [1] 2 3 4 5 Next page →

#110282 — Operator Precedence/Boolean Logic

From	Elizabeth Weiss <cake240@gmail.com>
Date	2016-06-21 20:40 -0700
Subject	Operator Precedence/Boolean Logic
Message-ID	<15997174-44d5-431c-8f90-a8d700921820@googlegroups.com>

Hi There, 

I am a little confused as to how this is False:

False==(False or True)

I would think it is True because False==False is true. 

I think the parenthesis are confusing me. 

(False==False) or True

This is True. Is it because False==False? And True==False is not True but that does not change that this is True. 

If someone could please explain as I am teaching Python to myself and am stuck on this that would be great. 
Thank you for your help!

[toc] | [next] | [standalone]

#110285

From	Ben Finney <ben+python@benfinney.id.au>
Date	2016-06-22 13:59 +1000
Message-ID	<mailman.24.1466567966.11516.python-list@python.org>
In reply to	#110282

Elizabeth Weiss <cake240@gmail.com> writes:

> Hi There, 

Welcome! Your questions are fine here, but you may like to know that we
also have a beginner-specific forum for collaborative tutoring
<URL:https://mail.python.org/mailman/listinfo/tutor>.

> I am a little confused as to how this is False:
> False==(False or True)
>
> I would think it is True because False==False is true.

What does ‘(False or True)’ evaluate to, when you try it in the REPL?

> I think the parenthesis are confusing me. 
> (False==False) or True
>
> This is True. Is it because False==False? And True==False is not True
> but that does not change that this is True. 

Heh. You express the confusion quite well :-)

Try the component expressions in the REPL (the interactive interpreter
session) and see if that helps::

    >>> False or True
    …
    >>> (False or True)
    …
    >>> True == False
    …
    >>> (True == False)
    …
    >>> False == False
    …
    >>> (False == False)
    …

Then, once you think you understand what those expressions evaluate to,
look again at how those results would work in a more complex
expression::

    >>> False == (False or True)
    …
    >>> (False == False) or True
    …

> Thank you for your help!

I hope that helps.

-- 
 \     “[W]e are still the first generation of users, and for all that |
  `\      we may have invented the net, we still don't really get it.” |
_o__)                                                   —Douglas Adams |
Ben Finney

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

#110357

From	Elizabeth Weiss <cake240@gmail.com>
Date	2016-06-22 21:19 -0700
Message-ID	<bb4b77d6-08e4-4d7a-ac5a-acc954598f48@googlegroups.com>
In reply to	#110285

On Tuesday, June 21, 2016 at 11:59:37 PM UTC-4, Ben Finney wrote:
> Elizabeth Weiss > writes:
> 
> > Hi There, 
> 
> Welcome! Your questions are fine here, but you may like to know that we
> also have a beginner-specific forum for collaborative tutoring
> <URL:https://mail.python.org/mailman/listinfo/tutor>.
> 
> > I am a little confused as to how this is False:
> > False==(False or True)
> >
> > I would think it is True because False==False is true.
> 
> What does ‘(False or True)’ evaluate to, when you try it in the REPL?
> 
> > I think the parenthesis are confusing me. 
> > (False==False) or True
> >
> > This is True. Is it because False==False? And True==False is not True
> > but that does not change that this is True. 
> 
> Heh. You express the confusion quite well :-)
> 
> Try the component expressions in the REPL (the interactive interpreter
> session) and see if that helps::
> 
>     >>> False or True
>     …
>     >>> (False or True)
>     …
>     >>> True == False
>     …
>     >>> (True == False)
>     …
>     >>> False == False
>     …
>     >>> (False == False)
>     …
> 
> Then, once you think you understand what those expressions evaluate to,
> look again at how those results would work in a more complex
> expression::
> 
>     >>> False == (False or True)
>     …
>     >>> (False == False) or True
>     …
> 
> > Thank you for your help!
> 
> I hope that helps.
> 
> -- 
>  \     “[W]e are still the first generation of users, and for all that |
>   `\      we may have invented the net, we still don't really get it.” |
> _o__)                                                   —Douglas Adams |
> Ben Finney

Thank you, Ben!

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

#110358

From	Elizabeth Weiss <cake240@gmail.com>
Date	2016-06-22 21:20 -0700
Message-ID	<95faf9bf-f027-45a2-9078-1386789aa24b@googlegroups.com>
In reply to	#110285

On Tuesday, June 21, 2016 at 11:59:37 PM UTC-4, Ben Finney wrote:
> Elizabeth Weiss > writes:
> 
> > Hi There, 
> 
> Welcome! Your questions are fine here, but you may like to know that we
> also have a beginner-specific forum for collaborative tutoring
> <URL:https://mail.python.org/mailman/listinfo/tutor>.
> 
> > I am a little confused as to how this is False:
> > False==(False or True)
> >
> > I would think it is True because False==False is true.
> 
> What does ‘(False or True)’ evaluate to, when you try it in the REPL?
> 
> > I think the parenthesis are confusing me. 
> > (False==False) or True
> >
> > This is True. Is it because False==False? And True==False is not True
> > but that does not change that this is True. 
> 
> Heh. You express the confusion quite well :-)
> 
> Try the component expressions in the REPL (the interactive interpreter
> session) and see if that helps::
> 
>     >>> False or True
>     …
>     >>> (False or True)
>     …
>     >>> True == False
>     …
>     >>> (True == False)
>     …
>     >>> False == False
>     …
>     >>> (False == False)
>     …
> 
> Then, once you think you understand what those expressions evaluate to,
> look again at how those results would work in a more complex
> expression::
> 
>     >>> False == (False or True)
>     …
>     >>> (False == False) or True
>     …
> 
> > Thank you for your help!
> 
> I hope that helps.
> 
> -- 
>  \     “[W]e are still the first generation of users, and for all that |
>   `\      we may have invented the net, we still don't really get it.” |
> _o__)                                                   —Douglas Adams |
> Ben Finney

Thank you, Ben!

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

#110290

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2016-06-22 16:02 +1000
Message-ID	<576a2a12$0$1534$c3e8da3$5496439d@news.astraweb.com>
In reply to	#110282

On Wednesday 22 June 2016 13:40, Elizabeth Weiss wrote:

> Hi There,
> 
> I am a little confused as to how this is False:
> 
> False==(False or True)
> 
> I would think it is True because False==False is true.

Remember that parentheses are always evaluated first. So Python evaluates:

False or True

first, which evaluates as True. Then it evaluates False == True, which is 
obviously False.

Why is "False or True" True? Well, consider this question:

Who is allowed on the rides at the amusement park?
- people over 18, regardless of their height;
- people under 18, if they are "this tall" (4ft 6in) or greater.

Is Fred (16 years old, and 5ft 6in tall) allowed on the ride? Only if:
- he is over 18, or taller than "this tall";
- which is "False or True"
- which is True



Does that help?


-- 
Steve

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

#110295

From	Christian Gollwitzer <auriocus@gmx.de>
Date	2016-06-22 08:26 +0200
Message-ID	<nkdb2m$5u0$1@dont-email.me>
In reply to	#110282

Am 22.06.16 um 05:40 schrieb Elizabeth Weiss:
> I am a little confused as to how this is False:
>
> False==(False or True)
>
> I would think it is True because False==False is true.
>
> I think the parenthesis are confusing me.

Are you thinking, by any chance, that "or" indicates a choice? Comparing 
False to either False "or" True? That is not the case.

"or" is an operator. "False or True" is *computed* and gives True, which 
is then compared to False by "==". Python works in these steps:

1) False ==  (False or True)
2) False ==  (True)
3) False


	Christian

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

#110300

From	Jussi Piitulainen <jussi.piitulainen@helsinki.fi>
Date	2016-06-22 10:14 +0300
Message-ID	<lf51t3p4rv8.fsf@ling.helsinki.fi>
In reply to	#110295

Christian Gollwitzer writes:

> Am 22.06.16 um 05:40 schrieb Elizabeth Weiss:
>> I am a little confused as to how this is False:
>>
>> False==(False or True)
>>
>> I would think it is True because False==False is true.
>>
>> I think the parenthesis are confusing me.
>
> Are you thinking, by any chance, that "or" indicates a choice?
> Comparing False to either False "or" True? That is not the case.
>
> "or" is an operator. "False or True" is *computed* and gives True,
> which is then compared to False by "==". Python works in these steps:
>
> 1) False ==  (False or True)
> 2) False ==  (True)
> 3) False

Similarly:

1) "coffee" == ("coffee" or "tea")
2) "coffee" == "coffee"
3) True

1) "tea" == ("coffee" or "tea")
2) "tea" == "coffee"
3) False

In programming languages that allow it, want("coffee" or "tea") is
probably not intended. One has to (want("coffee") or want("tea")).

I'm not trying to confuse. I'm trying to further illustrate how the
programming language notation differs from ordinary structures of
languages like English that may seem analogous until one learns that
they aren't, quite.

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

#110359

From	Elizabeth Weiss <cake240@gmail.com>
Date	2016-06-22 21:21 -0700
Message-ID	<ed7bf82e-7df9-4aac-a581-ad62b997bf0a@googlegroups.com>
In reply to	#110300

On Wednesday, June 22, 2016 at 3:15:02 AM UTC-4, Jussi Piitulainen wrote:
> Christian Gollwitzer writes:
> 
> > Am 22.06.16 um 05:40 schrieb Elizabeth Weiss:
> >> I am a little confused as to how this is False:
> >>
> >> False==(False or True)
> >>
> >> I would think it is True because False==False is true.
> >>
> >> I think the parenthesis are confusing me.
> >
> > Are you thinking, by any chance, that "or" indicates a choice?
> > Comparing False to either False "or" True? That is not the case.
> >
> > "or" is an operator. "False or True" is *computed* and gives True,
> > which is then compared to False by "==". Python works in these steps:
> >
> > 1) False ==  (False or True)
> > 2) False ==  (True)
> > 3) False
> 
> Similarly:
> 
> 1) "coffee" == ("coffee" or "tea")
> 2) "coffee" == "coffee"
> 3) True
> 
> 1) "tea" == ("coffee" or "tea")
> 2) "tea" == "coffee"
> 3) False
> 
> In programming languages that allow it, want("coffee" or "tea") is
> probably not intended. One has to (want("coffee") or want("tea")).
> 
> I'm not trying to confuse. I'm trying to further illustrate how the
> programming language notation differs from ordinary structures of
> languages like English that may seem analogous until one learns that
> they aren't, quite.

Thanks, Jussi! Very helpful.

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

#110302

From	Lawrence D’Oliveiro <lawrencedo99@gmail.com>
Date	2016-06-22 00:42 -0700
Message-ID	<56ecacd4-cc17-48ec-9830-57c8113d16f6@googlegroups.com>
In reply to	#110282

On Wednesday, June 22, 2016 at 3:40:22 PM UTC+12, Elizabeth Weiss wrote:
> I am a little confused as to how this is False:
> 
> False==(False or True)
> 
> I would think it is True because False==False is true. 
> 
> I think the parenthesis are confusing me. 

No, it is the meanings of the boolean operators in Python. The rules are:

* boolean operators don’t have to operate on boolean values. The language spec <https://docs.python.org/3/reference/expressions.html#boolean-operations> says:

    “...the following values are interpreted as false: False, None, numeric
    zero of all types, and empty strings and containers (including strings,
    tuples, lists, dictionaries, sets and frozensets). All other values are
    interpreted as true.”

I feel that’s a needlessly complicated rule. It would have been simpler if boolean operators (and conditional expressions like in if-statements and while-statements) only allowed values of boolean types. But that’s one of the few warts in the design of Python...

* the meaning of “A or B” is: “return A if it evaluates to true, else return B”. Correspondingly, the meaning of “A and B” is: “return A if it evaluates to false, else return B”.

Does that give you enough clues to understand what is going on?

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

#110353

From	Larry Hudson <orgnut@yahoo.com>
Date	2016-06-22 20:12 -0700
Message-ID	<YoudnV5Wro07zvbKnZ2dnUU7-b3NnZ2d@giganews.com>
In reply to	#110302

On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
[snip]
> I feel that’s a needlessly complicated rule. It would have been simpler if boolean operators (and conditional expressions like in if-statements and while-statements) only allowed values of boolean types. But that’s one of the few warts in the design of Python...
>

Wart??  I *strongly* disagree.  I find it one of the strengths of Python, it enhances Python's 
expressiveness.  Of course, everyone is entitled to their own opinion...and this is mine.

-- 
      -=- Larry -=-

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

#110354

From	Steven D'Aprano <steve@pearwood.info>
Date	2016-06-23 13:59 +1000
Message-ID	<576b5ea3$0$1595$c3e8da3$5496439d@news.astraweb.com>
In reply to	#110353

On Thu, 23 Jun 2016 01:12 pm, Larry Hudson wrote:

> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
> [snip]
>> I feel that’s a needlessly complicated rule. It would have been simpler
>> if boolean operators (and conditional expressions like in if-statements
>> and while-statements) only allowed values of boolean types. But that’s
>> one of the few warts in the design of Python...
>>
> 
> Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
> it enhances Python's
> expressiveness.  Of course, everyone is entitled to their own
> opinion...and this is mine.

Allowing any value as a truth value is just applying the principle of
duck-typing to booleans.

There are a pair of canonical truth values, namely True and False, but any
object can quack like a truth value. We often call them:

- true and false (as opposed to True and False);
- true-like and false-like;
- truthy and falsey

values.

Among the builtins, there's a general principle:

- values that represent something should be truthy;
- values that represent nothing should be falsey.

So we have falsey values:

- None
- zeroes (0, 0.0, 0j, etc)
- empty dict {}
- empty sets and frozensets
- empty strings '' and b'' (in Python 2: u'' and '')
- empty lists, tuples and other sequences

and truthy values:

- object
- non-zero numbers
- non-empty dicts
- non-empty sets and frozensets
- non-empty strings
- non-empty sequences

This is an improvement over other languages like Javascript, Ruby, etc where
the division between truthy and falsey appears to be fairly arbitrary.

-- 
Steven

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

#110361

From	Elizabeth Weiss <cake240@gmail.com>
Date	2016-06-22 21:23 -0700
Message-ID	<7f67743a-acae-4e02-91ab-86b4d5be5767@googlegroups.com>
In reply to	#110354

On Wednesday, June 22, 2016 at 11:59:44 PM UTC-4, Steven D'Aprano wrote:
> On Thu, 23 Jun 2016 01:12 pm, Larry Hudson wrote:
> 
> > On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
> > [snip]
> >> I feel that’s a needlessly complicated rule. It would have been simpler
> >> if boolean operators (and conditional expressions like in if-statements
> >> and while-statements) only allowed values of boolean types. But that’s
> >> one of the few warts in the design of Python...
> >>
> > 
> > Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
> > it enhances Python's
> > expressiveness.  Of course, everyone is entitled to their own
> > opinion...and this is mine.
> 
> Allowing any value as a truth value is just applying the principle of
> duck-typing to booleans.
> 
> There are a pair of canonical truth values, namely True and False, but any
> object can quack like a truth value. We often call them:
> 
> - true and false (as opposed to True and False);
> - true-like and false-like;
> - truthy and falsey
> 
> values.
> 
> Among the builtins, there's a general principle:
> 
> - values that represent something should be truthy;
> - values that represent nothing should be falsey.
> 
> So we have falsey values:
> 
> - None
> - zeroes (0, 0.0, 0j, etc)
> - empty dict {}
> - empty sets and frozensets
> - empty strings '' and b'' (in Python 2: u'' and '')
> - empty lists, tuples and other sequences
> 
> and truthy values:
> 
> - object
> - non-zero numbers
> - non-empty dicts
> - non-empty sets and frozensets
> - non-empty strings
> - non-empty sequences
> 
> This is an improvement over other languages like Javascript, Ruby, etc where
> the division between truthy and falsey appears to be fairly arbitrary.
> 
> 
> 
> 
> -- 
> Steven

Thanks, Steven!

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

#110378

From	Antoon Pardon <antoon.pardon@rece.vub.ac.be>
Date	2016-06-23 09:58 +0200
Message-ID	<mailman.56.1466668786.11516.python-list@python.org>
In reply to	#110354

Op 23-06-16 om 05:59 schreef Steven D'Aprano:
> On Thu, 23 Jun 2016 01:12 pm, Larry Hudson wrote:
>
>> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
>> [snip]
>>> I feel that’s a needlessly complicated rule. It would have been simpler
>>> if boolean operators (and conditional expressions like in if-statements
>>> and while-statements) only allowed values of boolean types. But that’s
>>> one of the few warts in the design of Python...
>>>
>> Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
>> it enhances Python's
>> expressiveness.  Of course, everyone is entitled to their own
>> opinion...and this is mine.
> Allowing any value as a truth value is just applying the principle of
> duck-typing to booleans.

What does that mean? As far as I understood, duck typing was that you
could define any class with the same attributes and methods as an other,
often a built in, at which point you could substitute instance of this
new class anywhere you originally expected instance of the old class.

My experience is that this doesn't work with booleans. When I need
real booleans, encountering whatever else that can act like a boolean,
is more often than not an indication something went wrong but the
detection of it going wrong is delayed, because almost everything
can act like a boolean. It is why I have sometime found the need
to write:

    if flag is True:

Because flag needed to be True, not truthy.

-- 
Antoon Pardon

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

#110379

From	Marko Rauhamaa <marko@pacujo.net>
Date	2016-06-23 11:16 +0300
Message-ID	<87a8icgw0d.fsf@elektro.pacujo.net>
In reply to	#110378

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> It is why I have sometime found the need to write:
>
>     if flag is True:
>
> Because flag needed to be True, not truthy.

Then, you have found the correct idiom for your rare need. You might
even want to consider:

   if flag is UP:
       ...
   elif flag is DOWN:
       ...
   else:
       assert flag is HALFMAST
       ...


I don't particularly like Python's falsey/truthy semantics, but I can
live with it. The biggest problem I have with it is the absence of an
emptiness predicate. I'd like to be able to write:

    if not leftover.empty():
        ...

or even:

    if not empty(leftover):
        ...

rather than having to say:

    if not leftover:
        ...

or:

    if len(leftover) > 0:    # no, I'd never write this
        ...


Marko

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

#110385

From	Lawrence D’Oliveiro <lawrencedo99@gmail.com>
Date	2016-06-23 01:53 -0700
Message-ID	<4e388a43-0191-4a48-8517-3ee3bdc50910@googlegroups.com>
In reply to	#110379

On Thursday, June 23, 2016 at 8:17:02 PM UTC+12, Marko Rauhamaa wrote:
>     if len(leftover) > 0:    # no, I'd never write this
>         ...

I regularly write “len(leftover) != 0”. Why not?

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

#110388

From	Marko Rauhamaa <marko@pacujo.net>
Date	2016-06-23 12:10 +0300
Message-ID	<871t3ogti9.fsf@elektro.pacujo.net>
In reply to	#110385

Lawrence D’Oliveiro <lawrencedo99@gmail.com>:

> On Thursday, June 23, 2016 at 8:17:02 PM UTC+12, Marko Rauhamaa wrote:
>>     if len(leftover) > 0:    # no, I'd never write this
>>         ...
>
> I regularly write “len(leftover) != 0”. Why not?

The __len__ method is not guaranteed to execute in O(1). See:

   <URL: https://docs.python.org/3/reference/datamodel.html?highlig
   ht=__len__#object.__len__>


Marko

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

#110391

From	Antoon Pardon <antoon.pardon@rece.vub.ac.be>
Date	2016-06-23 11:27 +0200
Message-ID	<mailman.62.1466674276.11516.python-list@python.org>
In reply to	#110388

Op 23-06-16 om 11:10 schreef Marko Rauhamaa:
> Lawrence D’Oliveiro <lawrencedo99@gmail.com>:
>
>> On Thursday, June 23, 2016 at 8:17:02 PM UTC+12, Marko Rauhamaa wrote:
>>>     if len(leftover) > 0:    # no, I'd never write this
>>>         ...
>> I regularly write “len(leftover) != 0”. Why not?
> The __len__ method is not guaranteed to execute in O(1). See:
>
>    <URL: https://docs.python.org/3/reference/datamodel.html?highlig
>    ht=__len__#object.__len__>

As far as I can see, neither is the __bool__ method.

-- 
Antoon.

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

#110397

From	Marko Rauhamaa <marko@pacujo.net>
Date	2016-06-23 12:53 +0300
Message-ID	<87oa6sfczf.fsf@elektro.pacujo.net>
In reply to	#110391

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Op 23-06-16 om 11:10 schreef Marko Rauhamaa:
>> The __len__ method is not guaranteed to execute in O(1). See:
>>
>>    <URL: https://docs.python.org/3/reference/datamodel.html?highlig
>>    ht=__len__#object.__len__>
>
> As far as I can see, neither is the __bool__ method.

Correct, but in the absence of an __empty__ method, __bool__ gives the
class the best opportunity to check for emptiness quickly.

This is not only a theoretical concern. It's quite common for data
structures not to maintain an element count because it's extra baggage
that's not always needed and any application could keep a track of.
However, an emptiness check is often trivial.


Marko

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

#110403

From	Antoon Pardon <antoon.pardon@rece.vub.ac.be>
Date	2016-06-23 12:54 +0200
Message-ID	<mailman.67.1466679335.11516.python-list@python.org>
In reply to	#110397

Op 23-06-16 om 11:53 schreef Marko Rauhamaa:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> Op 23-06-16 om 11:10 schreef Marko Rauhamaa:
>>> The __len__ method is not guaranteed to execute in O(1). See:
>>>
>>>    <URL: https://docs.python.org/3/reference/datamodel.html?highlig
>>>    ht=__len__#object.__len__>
>> As far as I can see, neither is the __bool__ method.
> Correct, but in the absence of an __empty__ method, __bool__ gives the
> class the best opportunity to check for emptiness quickly.
>
> This is not only a theoretical concern. It's quite common for data
> structures not to maintain an element count because it's extra baggage
> that's not always needed and any application could keep a track of.
> However, an emptiness check is often trivial.

Maybe something like this:

def empty(sq):
    try:
        iter(sq).next()
    except StopIteration:
        return False
    except:
        raise TypeError
    else:
        return True

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

#110404

From	Marko Rauhamaa <marko@pacujo.net>
Date	2016-06-23 13:59 +0300
Message-ID	<878txwf9w5.fsf@elektro.pacujo.net>
In reply to	#110403

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Op 23-06-16 om 11:53 schreef Marko Rauhamaa:
> Maybe something like this:
>
> def empty(sq):
>     try:
>         iter(sq).next()
>     except StopIteration:
>         return False
>     except:
>         raise TypeError
>     else:
>         return True

That may or may not be as effective as a boolean check. The point is,
Python has already declared that __bool__ is the canonical emptiness
checker. You could even say that it's the principal purpose of the
__bool__ method.


Marko

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

Page 1 of 5 [1] 2 3 4 5 Next page →

csiph-web

Operator Precedence/Boolean Logic

Contents

#110282 — Operator Precedence/Boolean Logic

#110285

#110357

#110358

#110290

#110295

#110300

#110359

#110302

#110353

#110354

#110361

#110378

#110379

#110385

#110388

#110391

#110397

#110403

#110404