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

#111492

On Thursday, June 30, 2016 at 10:52:50 PM UTC+5:30, Steven D'Aprano wrote:
> Okay, if you think that automata cannot be empty, I'll accept that. In that
> case, then I'll change my answer and say that __bool__ for automata should
> simply return True. All automata should be truthy.
> 

I am not sure with what tone of voice you are saying that

If ... “return True” is about as good -- ie useful -- as (say)

def __bool__(self):
  from random import random
  return int(2*random())

then I think we agree

But then there is a well-established behavior pattern in python
captured by the contexts that raise AttributeError/NameError/TypeError etc
viz For things that are undefined we are told politely they are undefined

IOW Why say something is useless and define it rather than just leave undefined
something that is ill-defined.

If on the other hand you are giving that “return True”as a serious useful definition?

If both you and Chris tripped up on a right definition of an “empty” automaton
and regex respectively, I believe it demonstrates that getting boolishness
for an arbitrary type right is at least non-trivial. [FWIW My belief: In
general its nonsensical]

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

#111494

From other thread:

On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote:
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
> 
> > Just that suggesting that python's bool notion is straightforward is an
> > unnecessary lie – especially to newbies.
> 
> Python's boolean concept is as simple as it gets -- what is not straightforward about it?

And to expand on my

On Saturday, July 16, 2016 at 11:18:48 AM UTC+5:30, Rustom Mody wrote:
> FWIW My belief: In general its nonsensical

C's 0 is false; rest-of-universe is true is a mess
Python increases the mess by making the false-y candidates also non-singleton

This seems to work for container-like objects like lists,strings,sets, etc
with None and 0 being somewhat elliptical analogues

But when we allow __bool__ to be available for any and every thing and give
it some implicit random definition, this is just plain nonsense.

[What is the bool-nature -- aka Buddha-nature -- of graphs question remains yet answered]

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

#111501

On Sat, 16 Jul 2016 03:58 pm, Rustom Mody wrote:

> 
> From other thread:
> 
> On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote:
>> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>> 
>> > Just that suggesting that python's bool notion is straightforward is an
>> > unnecessary lie – especially to newbies.
>> 
>> Python's boolean concept is as simple as it gets -- what is not
>> straightforward about it?
> 
> And to expand on my
> 
> On Saturday, July 16, 2016 at 11:18:48 AM UTC+5:30, Rustom Mody wrote:
>> FWIW My belief: In general its nonsensical
> 
> C's 0 is false; rest-of-universe is true is a mess

Really? In what way?

As far as I know, C requires bools to be ints, not arbitrary values, and the
compiler will enforce that. What mess do you get from C allowing 2 as well
as 1 to be treated as true?


> Python increases the mess by making the false-y candidates also
> non-singleton

So you say, but you haven't demonstrated this.


> This seems to work for container-like objects like lists,strings,sets, etc
> with None and 0 being somewhat elliptical analogues

Right. This is a good, concrete, practical example that duck-typed truthy
and falsey values DOES work: it works for numbers, it works for strings, it
works for containers.


> But when we allow __bool__ to be available for any and every thing and
> give it some implicit random definition, this is just plain nonsense.
> 
> [What is the bool-nature -- aka Buddha-nature -- of graphs question
> [remains yet answered]

No, I already answered that in the earlier thread. Graphs are collections or
sequences of nodes. An empty graph (one with zero nodes) should be falsey;
all other graphs (one or more nodes) should be truthy.

I say "should", not "must". Practicality beats purity: if your application
has a specific need for (let's say) a graph with exactly two cycles to be
considered falsey, and all others to be truthy, then you are free to define
your graph type that way. As an internal application-only class, that's
probably okay, but as a generic graph type in a library, it's probably a
bad idea.




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

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

#111505

On Sat, 16 Jul 2016 03:48 pm, Rustom Mody wrote:

> On Thursday, June 30, 2016 at 10:52:50 PM UTC+5:30, Steven D'Aprano wrote:
>> Okay, if you think that automata cannot be empty, I'll accept that. In
>> that case, then I'll change my answer and say that __bool__ for automata
>> should simply return True. All automata should be truthy.
>> 
> 
> I am not sure with what tone of voice you are saying that

A standard, non-sarcastic tone of voice.


> If ... “return True” is about as good -- ie useful -- as (say)
> 
> def __bool__(self):
>   from random import random
>   return int(2*random())
> 
> then I think we agree

No, I don't agree with that. "Emptiness" or "zeroness" or "falsity" doesn't
necessarily make sense for every single kind of object. If we were
modelling (say) Employees, then I would probably model all Employees as
truthy. That's easy to do: all objects are truthy by default, so I don't
have to do a thing.

If there is some concept of an "empty/null/do-nothing" automata, then I
would consider making such null automata falsey. But I'm no sure I would
care enough to bother. For example, functions are all truthy, even
do-nothing functions.


> But then there is a well-established behavior pattern in python
> captured by the contexts that raise AttributeError/NameError/TypeError etc
> viz For things that are undefined we are told politely they are undefined
> 
> IOW Why say something is useless and define it rather than just leave
> undefined something that is ill-defined.

You are forgetting that you're not necessarily encountering automata in a
context where you are expecting an automata and nothing else:

x = Turing_Machine(foo)
if x:
    x.run()
else:
    x.blibbet()


You may encounter one in code that is expecting arbitrary objects, without
caring whether they are floats or HTTPServers or re.MatchObjects or
automata or Employees or something else:

for obj in bunch_of_objects:
    if obj:
        turn_left()
    else:
        turn_right()


There's an argument in favour of Pascal-style "true booleans" that require
you to use True and False *only* in boolean contexts; and there's an
argument in favour of Python's truthiness where any object can duck-type in
a bool context; but what doesn't make sense is to have *some* objects be
usable as true/false, forcing you to write code like this everywhere you
have to deal with arbitrary truthy objects:


for obj in bunch_of_objects:
    try:
        # Okay for collections, sequences, ints, floats, None, 
        # FooManagers, HttpServers, Dogs, Horses, Pizzashops, etc.
        flag = bool(obj)
    except TypeError:
        # But not okay for Automata, Employees, Cats, PrintFormatters, etc.
        flag = True  # default to true, say
    if flag:
        turn_left()
    else:
        turn_right()


That's just awful language design. You should have either two booleans only,
or all objects should be booleans.



> 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?

 
> If both you and Chris tripped up on a right definition of an “empty”
> automaton and regex respectively, I believe it demonstrates that getting
> boolishness for an arbitrary type right is at least non-trivial. [FWIW My
> belief: In general its nonsensical]

Firstly, I disagree that I tripped up on anything. You haven't given any
reason to think that Automata objects shouldn't be truthy, and even if you
do, isn't that just a matter of opinion?

But in general, deciding on whether an arbitrary object should be truthy or
falsey is not hard, and most of the time you don't have to do a thing to
get the right behaviour.

- Does the object represent a collection or sequence? If so, then the right
behaviour is to delegate to `len(obj) != 0`.

- Does the object represent a number? If so, then the right behaviour is to
delegate to `obj != 0`.

- Does the object represent (in some sense) nothing rather than something?
That is, is it a reification of "there's nothing here"? E.g. something like
None in Python, null/nil pointers, Void, or Undefined. Then it should be
falsey.

- Otherwise, it represents something rather than nothing, and unless you
have pressing reason to do otherwise, it should be truthy.




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

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

#111509

On Sat, Jul 16, 2016 at 8:16 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> If both you and Chris tripped up on a right definition of an “empty”
>> automaton and regex respectively, I believe it demonstrates that getting
>> boolishness for an arbitrary type right is at least non-trivial. [FWIW My
>> belief: In general its nonsensical]
>
> Firstly, I disagree that I tripped up on anything. You haven't given any
> reason to think that Automata objects shouldn't be truthy, and even if you
> do, isn't that just a matter of opinion?

I also disagree that I "tripped up", but there is room for differing
decisions in API design, and this is one of them. I can't say
perfectly, from my armchair (which I'm not in anyway - way too
cumbersome for a desktop computer), which objects are capable of being
"empty" and which are not. The implementer of the automaton class or
the regex class has to decide what counts as "empty". As Steven says,
the default is that they're all truthy, and onus is on the implementer
to demonstrate that this object is functionally equivalent to 0 or an
empty collection. (And it's possible for ANYONE to get that wrong - cf
timedelta.)

ChrisA

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

#111510

On Sat, 16 Jul 2016 08:46 pm, Chris Angelico wrote:

> As Steven says,
> the default is that they're all truthy, and onus is on the implementer
> to demonstrate that this object is functionally equivalent to 0 or an
> empty collection. (And it's possible for ANYONE to get that wrong - cf
> timedelta.)

I think you're thinking of time values, not timedelta values. Until
recently, midnight was considered falsey just because it happened to be
implemented as 0 seconds:

[steve@ando ~]$ python3.3 -c "import datetime;print(bool(datetime.time(0)))"
False
[steve@ando ~]$ python3.6 -c "import datetime;print(bool(datetime.time(0)))"
True

That was a real bug, letting the concrete implementation show through into
the abstract API by accident, but it's corrected now.

timedelta values, being a difference between two times, have a qualitative
difference between delta = 0 and every other value. A difference of zero is
no difference at all, and it makes sense to make that falsey.



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

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

#111514

On Sat, Jul 16, 2016 at 9:02 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sat, 16 Jul 2016 08:46 pm, Chris Angelico wrote:
>
>> As Steven says,
>> the default is that they're all truthy, and onus is on the implementer
>> to demonstrate that this object is functionally equivalent to 0 or an
>> empty collection. (And it's possible for ANYONE to get that wrong - cf
>> timedelta.)
>
> I think you're thinking of time values, not timedelta values. Until
> recently, midnight was considered falsey just because it happened to be
> implemented as 0 seconds:
>
> [steve@ando ~]$ python3.3 -c "import datetime;print(bool(datetime.time(0)))"
> False
> [steve@ando ~]$ python3.6 -c "import datetime;print(bool(datetime.time(0)))"
> True
>
> That was a real bug, letting the concrete implementation show through into
> the abstract API by accident, but it's corrected now.
>
> timedelta values, being a difference between two times, have a qualitative
> difference between delta = 0 and every other value. A difference of zero is
> no difference at all, and it makes sense to make that falsey.

Umm, yes. That's the one. Time, not timedelta. My bad. Point still
stands, though - the concept of "midnight" does not truly equate to
"empty" or "zero", and that bug stood for a long time.

ChrisA

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

#111512

On Saturday, July 16, 2016 at 4:16:34 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Jul 16, 2016 at 8:16 PM, Steven D'Aprano  wrote:
> >> If both you and Chris tripped up on a right definition of an “empty”
> >> automaton and regex respectively, I believe it demonstrates that getting
> >> boolishness for an arbitrary type right is at least non-trivial. [FWIW My
> >> belief: In general its nonsensical]
> >
> > Firstly, I disagree that I tripped up on anything. You haven't given any
> > reason to think that Automata objects shouldn't be truthy, and even if you
> > do, isn't that just a matter of opinion?
> 
> I also disagree that I "tripped up", but there is room for differing
> decisions in API design, and this is one of them. I can't say
> perfectly, from my armchair (which I'm not in anyway - way too
> cumbersome for a desktop computer), which objects are capable of being
> "empty" and which are not. The implementer of the automaton class or
> the regex class has to decide what counts as "empty". As Steven says,
> the default is that they're all truthy, and onus is on the implementer
> to demonstrate that this object is functionally equivalent to 0 or an
> empty collection. (And it's possible for ANYONE to get that wrong - cf
> timedelta.)

Just to re-iterate what we are talking about (and before you continue 
to score self-goals):

You folks — Chris and Steven — likely know a lot more python than I do – no one
questioning that.

You also have a bizarre notion that python's property: “Everything has
auto-bool-nature” IS STRAIGHTFORWARD.

My point of those examples is to show that with such an outlook you will invariably trip up.

Python in fact has a well established rheostat for this:
Simple → Complex → Complicated

If we agree to this bool business being complicated then we are being honest
If we agree to it being complex — well euphemisms are necessary in civilized society I guess
If however you insist its simple, you will trip up.
And the fact that that may be nothing to do with trick questions posed by me is
seen in the other thread where Peter saw a subtle distinction in boolishness
that we all missed.

So yes “Anyone can get that wrong” is a self-goal
You are making my point and then saying you disagree.
With what/whom?   Yourself??

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

#111515

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

> You also have a bizarre notion that python's property: “Everything has
> auto-bool-nature” IS STRAIGHTFORWARD.

That's a very strong claim.

You're not just pointing out that there may be a few old corner cases here
and there where Python's treatment of bools fails to be straightforward, or
is a little harder than it appears at first glance. You're making the claim
that it is BIZARRE (grossly unconventional or unusual, beyond belief,
foolish, laughable, ludicrous, nonsensical, outrageous, ridiculous, crazy)
to think that it might be straightfoward. In other words, that it is
obviously, clearly not-straightforward.

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.

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 should not be hard to understand. So what part of this system is not
straightfoward?


(1) Is it that programming the required dunder methods is not necessarily
trivial for every imaginable object? Nobody said that had to be.


(2) Is it that it may be tricky for the designer of the class to map the
class values/objects into the true/false dichotomy? Python gives a simple
and, yes, straightforward metaphor to use: if an object represents nothing
(an empty container, null, void) then it should be falsey, otherwise it
should be truthy.

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.

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.)

(3) Is it that sometimes people write code involving boolean contexts that
may not be trivially understood and obviously bug free? Sure they do. So
what? Do you expect perfection of code for every feature?

(4) Or something else? If so, what is your basis for claiming that this is
not straightforward? What part, or parts, is not straightforward?




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

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

#111517

On 2016-07-16 17:27, Steven D'Aprano wrote:
> On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote:
[snip]

> 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.
>
[snip]

And if you're going to argue that zero is something, then you could also 
argue that false is something...

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

#111542

Heh! A flurry of opinions!
No time right now… other than to say thank you (MRAB) for this little gem:

On Saturday, July 16, 2016 at 10:29:02 PM UTC+5:30, MRAB wrote:
> On 2016-07-16 17:27, Steven D'Aprano wrote:
> > On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote:
> [snip]
> 
> > 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.
> >
> [snip]
> 
> And if you're going to argue that zero is something, then you could also 
> argue that false is something...

Likewise Chris’ example of the comparison of Pike and Python alternative
semantics

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

#111545

On Sun, Jul 17, 2016 at 1:43 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Heh! A flurry of opinions!
> No time right now… other than to say thank you (MRAB) for this little gem:
>
> On Saturday, July 16, 2016 at 10:29:02 PM UTC+5:30, MRAB wrote:
>> On 2016-07-16 17:27, Steven D'Aprano wrote:
>> > On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote:
>> [snip]
>>
>> > 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.
>> >
>> [snip]
>>
>> And if you're going to argue that zero is something, then you could also
>> argue that false is something...
>
> Likewise Chris’ example of the comparison of Pike and Python alternative
> semantics

So if you accept that there are different semantics that all have
validity, can you also accept that Python's model is not "bizarre"?

ChrisA

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

#111548

On Sunday, July 17, 2016 at 9:35:57 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jul 17, 2016 at 1:43 PM, Rustom Mody  wrote:
> > Heh! A flurry of opinions!
> > No time right now… other than to say thank you (MRAB) for this little gem:
> >
> > On Saturday, July 16, 2016 at 10:29:02 PM UTC+5:30, MRAB wrote:
> >> On 2016-07-16 17:27, Steven D'Aprano wrote:
> >> > On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote:
> >> [snip]
> >>
> >> > 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.
> >> >
> >> [snip]
> >>
> >> And if you're going to argue that zero is something, then you could also
> >> argue that false is something...
> >
> > Likewise Chris’ example of the comparison of Pike and Python alternative
> > semantics
> 
> So if you accept that there are different semantics that all have
> validity, can you also accept that Python's model is not "bizarre"?
> 
> ChrisA

I am sure Chris you can distinguish between:

- Python’s (bool) model is bizarre
- The model “Everything has auto-bool-nature” is bizarre
- The notion « “Everything has auto-bool-nature” is straightforward » is bizarre


My earlier statement (with emphasis in original):
> You also have a bizarre notion that python's property: “Everything has
> auto-bool-nature” IS STRAIGHTFORWARD.

If you like you can take me to task for not being sufficiently punctilious 
about quote-marks as I am now.
[And remember your objections to my (mis)use of unicode <wink>]

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

#111549

On Sunday, July 17, 2016 at 12:15:40 PM UTC+5:30, Rustom Mody wrote:
> On Sunday, July 17, 2016 at 9:35:57 AM UTC+5:30, Chris Angelico wrote:
> > On Sun, Jul 17, 2016 at 1:43 PM, Rustom Mody  wrote:
> > > Heh! A flurry of opinions!
> > > No time right now… other than to say thank you (MRAB) for this little gem:
> > >
> > > On Saturday, July 16, 2016 at 10:29:02 PM UTC+5:30, MRAB wrote:
> > >> On 2016-07-16 17:27, Steven D'Aprano wrote:
> > >> > On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote:
> > >> [snip]
> > >>
> > >> > 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.
> > >> >
> > >> [snip]
> > >>
> > >> And if you're going to argue that zero is something, then you could also
> > >> argue that false is something...
> > >
> > > Likewise Chris’ example of the comparison of Pike and Python alternative
> > > semantics
> > 
> > So if you accept that there are different semantics that all have
> > validity, can you also accept that Python's model is not "bizarre"?
> > 
> > ChrisA
> 
> I am sure Chris you can distinguish between:
> 
> - Python’s (bool) model is bizarre
> - The model “Everything has auto-bool-nature” is bizarre
> - The notion « “Everything has auto-bool-nature” is straightforward » is bizarre
> 
> 
> My earlier statement (with emphasis in original):
> > You also have a bizarre notion that python's property: “Everything has
> > auto-bool-nature” IS STRAIGHTFORWARD.
> 
> If you like you can take me to task for not being sufficiently punctilious 
> about quote-marks as I am now.
> [And remember your objections to my (mis)use of unicode <wink>]

To add to that:

This is my first post in this thread:
https://mail.python.org/pipermail/python-list/2016-June/710678.html

I dont think I need to change much what is there other than to say this:
A snarky tone is unconducive to a serious discussion.
So I could restate that without the snark… something which I believe I’ve 
already done in recent posts

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

#111552

On Sun, Jul 17, 2016 at 4:44 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> I am sure Chris you can distinguish between:
>
> - Python’s (bool) model is bizarre
> - The model “Everything has auto-bool-nature” is bizarre
> - The notion « “Everything has auto-bool-nature” is straightforward » is bizarre
>
>
> My earlier statement (with emphasis in original):
>> You also have a bizarre notion that python's property: “Everything has
>> auto-bool-nature” IS STRAIGHTFORWARD.

I can distinguish them, yes. But Python's boolification model is
fundamentally the same as the model "Everything has auto-bool-nature".
So those two aren't really all that different, save that one of them
is language-agnostic.

I understand your third statement, but I posit that these last points
have proven it false. There are clearly a number of viable semantic
systems:

1) REXX and, I think, Pascal: there are two specific values that may
be used in conditionals, and anything else is an error
2) Everything is legal in a conditional, and has a truth value
2a) Pike: 0 is false, every other object is true, unless it defines a
magic method
2b) Python: Empty values and collections are false, everything else is
true, unless it defines a magic method
2c) JavaScript: 0, null, undefined, nan, "", false are false,
everything else is true, including all objects (no magic method
option)
3) Machine code: There are no conditionals - just CPU flags that you
can jump or not jump on.

All of them work. So you could *disagree* with the statement that
Python's model is straight-forward, but you cannot say that this
statement is *bizarre*.

ChrisA

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

#111555

On Sunday, July 17, 2016 at 7:33:19 PM UTC+12, Chris Angelico wrote:
> 1) REXX and, I think, Pascal: there are two specific values that may
> be used in conditionals, and anything else is an error

Worth comparing how two different languages deal with strict enforcement of booleans:
* Modula-2 does it right: BOOL is a separate type which is required for conditionals, but
    + the ORD and VAL functions offer typesafe conversions to and from integers, and
    + BOOL can be used as an array index type, just like any other enumerated type.
* Java does it wrong: not only does it not provide easy conversions, but it doesn’t allow enumerations to be used as array index types.

Python would do well to learn from the Modula-2 style.

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

#111564

On Sun, 17 Jul 2016 05:44 pm, Lawrence D’Oliveiro wrote:

> On Sunday, July 17, 2016 at 7:33:19 PM UTC+12, Chris Angelico wrote:
>> 1) REXX and, I think, Pascal: there are two specific values that may
>> be used in conditionals, and anything else is an error
> 
> Worth comparing how two different languages deal with strict enforcement
> of booleans: 

> * Modula-2 does it right: BOOL is a separate type which is 
> required for conditionals, but
>     + the ORD and VAL functions offer typesafe conversions to and from
>     integers, and 
>     + BOOL can be used as an array index type, just like any 
>     other enumerated type.

That's also the Pascal model, which is no surprise, since Modula-2 and
Pascal are both invented by the same person, Nicholas(?) Wirth.

I'll certainly agree that the Pascal/Modula-2 model for bools is a good
model. On balance, I think that I'd argue:

- in statically typed languages, I'd look for the Pascal model;
- in dynamically typed languages, I'd look for something that 
  matches Python's truthiness rules;
- or at least some other consistent, useful and simple metaphor 
  for truthiness;
- a mere collection of objects which happen to be arbitrarily 
  treated as truthy or falsey (like Ruby and Javascript?), 
  lacking any consistent metaphor, is in some ways the worst
  of both worlds.




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

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

#111569

On Sun, 17 Jul 2016 04:44 pm, Rustom Mody wrote:

> My earlier statement (with emphasis in original):
>> You also have a bizarre notion that python's property: “Everything has
>> auto-bool-nature” IS STRAIGHTFORWARD.

I'm still waiting to hear in what way it is not straightforward. You keep
insisting that it isn't, but haven't told us in what way it is not.


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

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

#111579

On Sunday, July 17, 2016 at 4:32:36 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 17 Jul 2016 04:44 pm, Rustom Mody wrote:
> 
> > My earlier statement (with emphasis in original):
> >> You also have a bizarre notion that python's property: “Everything has
> >> auto-bool-nature” IS STRAIGHTFORWARD.
> 
> I'm still waiting to hear in what way it is not straightforward. You keep
> insisting that it isn't, but haven't told us in what way it is not.

The re/automaton/graph examples were towards this only and I think we are 
running in circles on this.  [Note the persons involved and even the specific
types involved are in a sense not relevant]

There is however one point that I briefly alluded that can be expanded on, viz.
Python’s bool behavior is inconsistent with rest of python’s standard behavior.

>>> class C:
...   pass
... 
>>> c=C()
>>> c+c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'instance' and 'instance'
>>> c.a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: C instance has no attribute 'a'
>>> a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

IOW the details — AttributeError/NameError/TypeError — may differ but in general
python has a well-established (and IMHO kind) behavior, if programmer fails
to define something python helpfully says that and makes no random guesses.

The extremal behavior at the other end of the spectum is probably html:
Whatever html you throw at whatever browser it will be rendered in some way 
or other.  [Some people like this — standards are for wimps]

For bools python is closer to html than to its normal peremptory default:

>>> if c:
...   print "Yes"
... else:
...   print "No"
... 
Yes

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

#111581

On Mon, 18 Jul 2016 01:00 am, Rustom Mody wrote:

>> I'm still waiting to hear in what way it is not straightforward. You keep
>> insisting that it isn't, but haven't told us in what way it is not.
> 
> The re/automaton/graph examples were towards this only and I think we are
> running in circles on this.  [Note the persons involved and even the
> specific types involved are in a sense not relevant]

Ah, so its a secret, is it? ;-)


> There is however one point that I briefly alluded that can be expanded on,
> viz. Python’s bool behavior is inconsistent with rest of python’s standard
> behavior.

"Inconsistent" is too strong. Treatment of bools is certainly different from
(say) arithmetic. Python doesn't assume that every object can duck-type as
a number -- there's no standard protocol for coercing HTTPServer objects
into floats, for example.

But bools are not the only "universal" type. Strings are too. 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. If you define
neither, you will inherit from object. If you are using a classic class in
Python 2, you will inherit the built-in conversion.

Likewise equality: == is expected to work with *every* class, without
exception, so if you fail to define an __eq__ method, Python will use its
own default behaviour (which is to compare object identity).

There are a small, but very important, set of functions which are expected
to work on all objects, and coercion to bool is one of them.


> IOW the details — AttributeError/NameError/TypeError — may differ but in
> general python has a well-established (and IMHO kind) behavior, if
> programmer fails to define something python helpfully says that and makes
> no random guesses.

There is *no random guessing* involved. I've already gone through the steps
of the bool protocol two, three, maybe four times. Why do you misrepresent
this as "random guesses"? There's no element of chance, the protocol is
completely deterministic and documented. There's a preferred API,
__nonzero__ in Python 2 and __bool__ in Python 3, if that isn't defined
there's a fallback using __len__, if that's not defined then the usual
rules of inheritance apply and you inherit from your superclasses.




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

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

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

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

csiph-web