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

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

Operator Precedence/Boolean Logic

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

Contents

  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 5 of 5 — ← Prev page 1 2 3 4 [5]

#111582

On Mon, 18 Jul 2016 01:58 am, Steven D'Aprano wrote:

> All objects
> can be coerced to strings, using either str() or repr(). If you define
> only one of __str__ or __repr__, Python will use the other.

Er, sorry, that was incoherent. I hit Send too quick, without editing.

What I meant to say was, if you *fail* to define both __str__ and __repr__,
Python will use whichever you define in place of the missing one.

And of course, if you define neither, then you will inherit from object.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

#111518

On Sun, Jul 17, 2016 at 2:27 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> If you really mean your words, and don't wish to step back and make a less
> extreme claim, then you ought to be easily able to show that Python's use
> of bools hardly ever works. It's clearly a terrible idea, almost every use
> of it is a failure, even Blind Freddy can see that it is hard to use and
> not straightforward.

Anecdotal, yet important, factoid: When I teach Python to people
who've come from other languages, I explain it as: "In Python,
anything that represents emptiness is false. Everything else is
true.". So far, not a single student has failed to understand this,
and quite a few have thanked me for the simplicity (as if it's
credited to me, rather than just being a reflection of Python's
reality).

> The truthiness API is straightforward. Any value or object is usable in a
> boolean context, and there is a well-defined protocol for deciding whether
> arbitrary objects are considered true or false:
>
> * If the class defined a __nonzero__ (or __bool__ in Python 3) method, then
> the truthiness of the object is given by the result of calling that method.
>
> * If there is no __nonzero__ (or __bool__) method, but the class defines
> __len__, which returns zero, then the object is deemed falsey, otherwise it
> is deemed to be truthy.
>
> * If the class lacks both dunder methods, then the object is deemed truthy.

This isn't how truthiness is generally understood, though. Do you
explain to someone that (1).__bool__() returns True, or do you simply
say that 1, being a non-zero number, is true?

> But that doesn't mean that every imaginable class trivially maps into that
> dichotomy. Suppose we create a tri-state logic class, with three states
> Yes, No and Maybe. Obviously Yes should map to True, and No to False. What
> should Maybe map to? We may spend many sleepless hours weighing up the pros
> and cons of mapping Maybe to True versus Maybe to False. Or we might flip a
> coin.

Maybe can also raise an exception in __bool__ if it likes. Or, to
emphasize the tri-state nature of your logic class, *all* your
instances could raise, with a message saying that "if x:" should be
"if x >= tri.Maybe:" or "if x is tried.and.True" depending on how you
want to handle Maybe.

Ultimately, though, computers don't work with Maybes. They work with
concrete yes/no answers: should I run this code or not? (In
assembly/machine language, probably "should I take this jump or not"
covers it all.) Somewhere along the way, you have to turn that Maybe
in to either True or False, and that should be *before* you're asking
the question "if x:". Perhaps "Maybe" really means "Inherit" (as in
the DeScribe style sheet system; you have a tree of styles, and a
style could say "Bold: True" or "Bold: False", but if it doesn't, it's
shown as "Bold: Maybe" but really means "Bold: Same as parent"), in
which case you resolve it with "while x == tri.Maybe: x =
self.parent.x" before doing the lookups. Or perhaps Maybe means "the
user didn't enter a value", in which case you go with some global
default. Or perhaps it means "the data is too borderline to call this
one", in which case you flip a coin. Actual physical coin, mind, no
simulations here!

> And yes, Rustom, I'm very familiar with the philosophical objections to the
> something/nothing distinction. "Is zero truly nothing, or is it some thing
> distinct from the absence of any number?" I'm not interested in that
> argument. Let the philosophers count angels, but as far as Python code
> goes, I'm an intuitionist: if I have zero sheep, that's the same as not
> having any sheep, or having no sheep.
>
> I'm more sympathetic to the view that an empty list is different from
> absence of a list, therefore it's something, not nothing. Fine, if that's
> the way you want to reason, go right ahead and do so when you write your
> own language. But in Python, practicality wins, and empty sequences and
> collections are treated as "nothing". (It's a metaphor, not a deep
> philosophical axiom.)

Pike took the opposite view - an empty array is still true. Did you
put up a new shopping list? Yes, there's a list there, even though
it's currently empty. Both make sense, and both languages have very
simple definitions of "this is true, that is false". (And both permit
user-defined types to choose whether they're truthy or falsey, so of
course someone somewhere has made a pathological case, guaranteed.)
Python says that having zero sheep is the same as not having any
sheep; Pike says that a box of doughnuts is still a box even when
you've eaten all the doughnuts.

Most importantly, neither of them is "bizarre". (In most practical
usage, it actually works out pretty much the same way.) Rustom, I
await evidence from you that (a) new Python programmers are massively
confused because of the boolification rules, or (b) transitioning
programmers (new to Python but with experience in some other language)
are confused, or (c) that this is more of a bug magnet than comparable
features, while providing less useful functionality. Go! Prove to us.

ChrisA

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

#111511

Earlier you said:

> > 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a
> > graph..."
>  
> I would make the empty graph (zero nodes) falsey, and non-empty graphs (one
> or more nodes) truthy.
>  
>  
> > 2. Automata which in a way are special kinds of graphs
>  
> As above.


Now you say:

> > If on the other hand you are giving that “return True”as a serious useful
> > definition?
>  
> Sure. An automata is an object, and by default, all objects are "something"
> and hence truthy. That's the "no-brainer" answer, it requires no
> justification at all. If you think the answer should be something else,
> *that* is what needs justification. Why shouldn't it be truthy? 


How do we put these two together?

Maybe thusly?
https://en.wikibooks.org/wiki/Sufism/Nasrudin#Of_any_two_options_choose_the_third

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

#111516

On Sat, 16 Jul 2016 10:15 pm, Rustom Mody wrote:

> Earlier you said:
> 
>> > 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a
>> > graph..."
>>  
>> I would make the empty graph (zero nodes) falsey, and non-empty graphs
>> (one or more nodes) truthy.
>>  
>>  
>> > 2. Automata which in a way are special kinds of graphs
>>  
>> As above.

If automata are graphs, and there is a zero-node graph that represents an
automation, then it should be falsey. If there is no such "empty
automation", then there shouldn't be. Was that unclear? If I failed to make
that obvious enough for you to understand, then I apologise.

It may be that you feel that there's no such thing as an empty automation.
Okay, that seems reasonable to me too. One can map functions to
flow-charts, which are a special kind of graph too. But a flow chart with
no elements is no flow chart at all: even the identity function, or the
do-nothing procedure, will be represented by a flow chart with at least one
node. So there are no falsey functions. Maybe there are no falsey automata
either.



> Now you say:
> 
>> > If on the other hand you are giving that “return True”as a serious
>> > useful definition?
>>  
>> Sure. An automata is an object, and by default, all objects are
>> "something" and hence truthy. That's the "no-brainer" answer, it requires
>> no justification at all. If you think the answer should be something
>> else, *that* is what needs justification. Why shouldn't it be truthy?
> 
> 
> How do we put these two together?

Um, in the obvious, straightforward way?

What part of my statements is giving you trouble? Should I use smaller
words? Bigger words? Draw a picture?

Automata were *your* idea. I have no concept of what *your* idea of automata
are, except that *you* claim that they are a kind of graph. If you want to
specify the semantics of automata that you consider important in detail,
then perhaps we can decide which ones should be falsey (if any). Otherwise
I'm reduce to talking in generalities, as the question is under-specified.

If there are automata equivalent to the empty graph (graph with no nodes),
then they should be falsey. All others (those equivalent to graphs with one
or more nodes) should be truthy. If you disagree, well, Rustom, it's YOUR
class, you tell me under what conditions you think an automation object
should be considered truthy or falsey.

Mu is not an option. You have to pick one or the other.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

#110783

On 2016-06-29, Steven D'Aprano <steve@pearwood.info> wrote:

> To Nick, having 1+True return 2 is an accident of implementation,

My recollection is that it was not an accident of impliementation.  It
was an intentional descision to provide compatibility with many years
worth of programs that were written before there was either a boolean
type or built-in True/False integer values.

Those programs often did this at the top:

  True = 1
  False = 0

Having True and False evaluate as 1 and 0 in an integer expression
context guaranteed that those programs would to continue to work with
minimal changes.

-- 
Grant Edwards               grant.b.edwards        Yow! Life is a POPULARITY
                                  at               CONTEST!  I'm REFRESHINGLY
                              gmail.com            CANDID!!

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

#110784

On 2016-06-29, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2016-06-29, Steven D'Aprano <steve@pearwood.info> wrote:
>> To Nick, having 1+True return 2 is an accident of implementation,
>
> My recollection is that it was not an accident of impliementation.  It
> was an intentional descision to provide compatibility with many years
> worth of programs that were written before there was either a boolean
> type or built-in True/False integer values.
>
> Those programs often did this at the top:
>
>   True = 1
>   False = 0
>
> Having True and False evaluate as 1 and 0 in an integer expression
> context guaranteed that those programs would to continue to work with
> minimal changes.

I thought it was more for things like this:

  "%d widget%s" % (widgets, (widgets != 1) * "s")

i.e. using boolean expressions as numeric expressions, rather than
explicitly setting the identifiers True and False to be numbers.

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

#110789

On Thu, 30 Jun 2016 01:00 am, Grant Edwards wrote:

> On 2016-06-29, Steven D'Aprano <steve@pearwood.info> wrote:
> 
>> To Nick, having 1+True return 2 is an accident of implementation,
> 
> My recollection is that it was not an accident of impliementation.  It
> was an intentional descision to provide compatibility with many years
> worth of programs that were written before there was either a boolean
> type or built-in True/False integer values.

You're right ... I was thinking accident of history and wrote accident of
implementation :-(


-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

#110395

On 23.06.2016 11:17, Steven D'Aprano wrote:
> [ ... ]
> We can derive arithmetic from set theory.

IMO not, resp. not really. But that would make a another item, pretty 
off-topic from Python.

Should you know a place where to continue, would like to follow up.

Thanks BTW.

>   Zero is very special: it is defined
> as the empty set:
>
> 0: {}
>
> The successor of zero (namely, one) is the set of all empty sets:
>
> 1: {{}}
>
> Two is the set of zero and one:
>
> 2 = {{}, {{}}}
>
> and so forth.
>
>
>

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

#110376

On Thursday 23 June 2016 14:47, Lawrence D’Oliveiro wrote:

> On Thursday, June 23, 2016 at 3:12:52 PM UTC+12, Larry Hudson wrote:
>> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
>>> * 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.

As I described in my earlier email, it isn't complicated, at least not the way 
builtins are modelled.


>>> 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.
> 
> Tightening it up would rule out a whole class of common errors,

Hardly common. The only two exceptions I've seen are:

- people surprised by midnight being false, but that is fixed in 3.5; 
- people surprised that empty or exhausted iterables don't evaluate as false

and the first of those is pretty rare.

But even if you were right, and I disagree that you are, "fixing" this would 
break backwards compatibility and cause vast amounts of working code to stop 
working. That is much worse than the "problem".


> from
> misunderstanding (or forgetting) the rule about what exactly gets interpreted
> as true and what as false <https://bugs.python.org/issue13936>
> <http://stackoverflow.com/questions/28116931/datetime-time0-0-evaluates-as-
false-in-boolean-context>.

Or... we could fix time objects, as was done.


-- 
Steve

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

#110416

On Thu, Jun 23, 2016, at 02:34, Andreas Röhler wrote:
> Indeed, why should the result of 4 - 4 have a different truth-value
> than 4 - 3 ? This implementation seems to be a legacy from languages
> without boolean types.

A set which included Python until version 2.3.

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

#110375

Am 23.06.16 um 05:12 schrieb Larry Hudson:
> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
>> 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.

https://xkcd.com/1172/

	Christian

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

#110360

On Wednesday, June 22, 2016 at 3:42:24 AM UTC-4, Lawrence D’Oliveiro wrote:
> 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?

Thanks, Lawrence!

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

#110310

On Tue, Jun 21, 2016 at 8:40 PM, Elizabeth Weiss <cake240@gmail.com> 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.
>
> 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!
> --
> https://mail.python.org/mailman/listinfo/python-list
>

You have 2 comparisons here .  The first is inside the parenthesis, (False
or True) evaluates to True.  What remains of the expression is False ==
True, which is False.

-Jorge
(Reposted because I replied to the OP directly, instead of to the list)

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

#110315

On Tue, Jun 21, 2016, at 23: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. 

"False or True" is True, and then it reduces to "False == True" which is
false.

There's no "x == (y or z)" construct to compare x separately to both y
and z, the "or" will evaluate to the first one that's true and then is
used in the rest of the expression. If you wanted to write "x == y or x
== z" with only a single x, you'd do "x in (y, z)".

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

#110335

On 22/06/16 04:40, Elizabeth Weiss wrote:
> I am a little confused as to how this is False:
>
> False==(False or True)

Other people have explained why the expression evaluates as it does - 
the sub-expression "False or True" evaluates to True (as one of the 
operands is truthy). Your expression then becomes "False == True", which 
is of course false.

To get the construct you were expecting (is the thing on the left hand 
side equal to one of the things on the right hand side), you can use 
Python's "in" keyword to "search" a collection (list, tuple, set, 
dictionary etc) that contains the things you are trying to match:

 >>> False in (False, True) # tuple

 >>> False in [False, True] # list

 >>> False in {False, True} # set

 >>> False in {False: None, True: None} # dict

HTH,
E.

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

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

csiph-web