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

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

Equivalent code to the bool() built-in function

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

Contents

  Equivalent code to the bool() built-in function candide <candide@free.invalid> - 2011-04-16 22:24 +0200
    Re: Equivalent code to the bool() built-in function Chris Rebert <clp2@rebertia.com> - 2011-04-16 13:58 -0700
      Re: Equivalent code to the bool() built-in function Ben Finney <ben+python@benfinney.id.au> - 2011-04-17 07:38 +1000
        Re: Equivalent code to the bool() built-in function candide <candide@free.invalid> - 2011-04-17 01:51 +0200
          Re: Equivalent code to the bool() built-in function Chris Rebert <clp2@rebertia.com> - 2011-04-16 17:16 -0700
          Re: Equivalent code to the bool() built-in function Ben Finney <ben+python@benfinney.id.au> - 2011-04-17 12:39 +1000
            Re: Equivalent code to the bool() built-in function candide <candide@free.invalid> - 2011-04-17 10:38 +0200
              Re: Equivalent code to the bool() built-in function Chris Angelico <rosuav@gmail.com> - 2011-04-17 18:46 +1000
                Re: Equivalent code to the bool() built-in function Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-18 12:12 +1200
                  Re: Equivalent code to the bool() built-in function John Nagle <nagle@animats.com> - 2011-04-18 12:58 -0700
                    Re: Equivalent code to the bool() built-in function Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-19 12:18 +1200
                    Re: Equivalent code to the bool() built-in function Christian Heimes <lists@cheimes.de> - 2011-04-19 03:39 +0200
                    Re: Equivalent code to the bool() built-in function Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2011-04-19 11:53 +0530
                      Re: Equivalent code to the bool() built-in function Grant Edwards <invalid@invalid.invalid> - 2011-04-19 14:23 +0000
                        Re: Equivalent code to the bool() built-in function Jean-Paul Calderone <calderone.jeanpaul@gmail.com> - 2011-04-19 08:43 -0700
                          Re: Equivalent code to the bool() built-in function Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-20 11:59 +1200
                        Re: Equivalent code to the bool() built-in function Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-28 16:45 +0000
                          Re: Equivalent code to the bool() built-in function Duncan Booth <duncan.booth@invalid.invalid> - 2011-04-28 17:18 +0000
                    Re: Equivalent code to the bool() built-in function Chris Angelico <rosuav@gmail.com> - 2011-04-19 16:26 +1000
                      Re: Equivalent code to the bool() built-in function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-19 08:43 +0000
                        Re: Equivalent code to the bool() built-in function Chris Angelico <rosuav@gmail.com> - 2011-04-19 19:00 +1000
                        Re: Equivalent code to the bool() built-in function Westley Martínez <anikom15@gmail.com> - 2011-04-19 06:43 -0700
              Re: Equivalent code to the bool() built-in function Ben Finney <ben+python@benfinney.id.au> - 2011-04-17 19:46 +1000
                Re: Equivalent code to the bool() built-in function candide <candide@free.invalid> - 2011-04-18 01:22 +0200
                  Re: Equivalent code to the bool() built-in function Ben Finney <ben+python@benfinney.id.au> - 2011-04-18 09:46 +1000
                  Re: Equivalent code to the bool() built-in function Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-18 12:08 +1200
                  Re: Equivalent code to the bool() built-in function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-18 00:22 +0000
                    Re: Equivalent code to the bool() built-in function Chris Angelico <rosuav@gmail.com> - 2011-04-18 10:52 +1000
                    Re: Equivalent code to the bool() built-in function Duncan Booth <duncan.booth@invalid.invalid> - 2011-04-18 10:01 +0000
              Re: Equivalent code to the bool() built-in function Daniel Kluev <dan.kluev@gmail.com> - 2011-04-17 21:11 +1100
        Re: Equivalent code to the bool() built-in function Daniel Kluev <dan.kluev@gmail.com> - 2011-04-18 10:45 +1100
          Re: Equivalent code to the bool() built-in function Ben Finney <ben+python@benfinney.id.au> - 2011-04-18 10:36 +1000
        Re: Re: Equivalent code to the bool() built-in function Chris Angelico <rosuav@gmail.com> - 2011-04-18 11:52 +1000
        Re: Re: Equivalent code to the bool() built-in function Dave Angel <davea@ieee.org> - 2011-04-17 21:46 -0400
        Re: Re: Equivalent code to the bool() built-in function Daniel Kluev <dan.kluev@gmail.com> - 2011-04-18 14:16 +1100
        Re: Equivalent code to the bool() built-in function Ned Deily <nad@acm.org> - 2011-04-17 21:40 -0700
        Re: Equivalent code to the bool() built-in function Chris Angelico <rosuav@gmail.com> - 2011-04-18 14:53 +1000
          Re: Equivalent code to the bool() built-in function Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-19 12:22 +1200
            Re: Equivalent code to the bool() built-in function Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-28 16:55 +0000
        Re: Equivalent code to the bool() built-in function Chris Rebert <clp2@rebertia.com> - 2011-04-17 22:49 -0700
          Re: Equivalent code to the bool() built-in function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-18 06:14 +0000
        Re: Equivalent code to the bool() built-in function Chris Angelico <rosuav@gmail.com> - 2011-04-18 16:03 +1000
    Re: Equivalent code to the bool() built-in function Ben Finney <ben+python@benfinney.id.au> - 2011-04-17 07:13 +1000
      Re: Equivalent code to the bool() built-in function candide <candide@free.invalid> - 2011-04-17 01:51 +0200
    Re: Equivalent code to the bool() built-in function Raymond Hettinger <python@rcn.com> - 2011-04-18 01:33 -0700
      Re: Equivalent code to the bool() built-in function candide <candide@free.invalid> - 2011-04-18 11:19 +0200

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

#3345 — Equivalent code to the bool() built-in function

Consider the following code :

# --------------------------------------
def bool_equivalent(x):
     return True if x else False


# testing ...

def foo(x):
     return 10*x

class C:
     pass

for x in [42, ("my","baby"), "baobab", max, foo, C] + [None, 0, "", [], 
{},()]:
     print bool(x)==bool_equivalent(x)
# --------------------------------------


Is the bool_equivalent() function really equivalent to the bool() 
built-in function ?

[toc] | [next] | [standalone]

#3347

On Sat, Apr 16, 2011 at 1:24 PM, candide <candide@free.invalid> wrote:
> Consider the following code :
>
> # --------------------------------------
> def bool_equivalent(x):
>    return True if x else False
>
>
> # testing ...
>
> def foo(x):
>    return 10*x
>
> class C:
>    pass
>
> for x in [42, ("my","baby"), "baobab", max, foo, C] + [None, 0, "", [],
> {},()]:
>    print bool(x)==bool_equivalent(x)
> # --------------------------------------
>
>
> Is the bool_equivalent() function really equivalent to the bool() built-in
> function ?

The ternary operator, if-statement, and `while` all do the equivalent
of an implicit bool() on their condition, so bool_equivalent() will
always give the same result as bool() because it's indeed using the
moral equivalent of bool() behind the scenes.
That is, `True if x else False` conceptually gets compiled down to
`True if bool(x) == 1 else False` (but without doing a run-time lookup
of "bool").

Cheers,
Chris
--
http://blog.rebertia.com

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

#3349

Chris Rebert <clp2@rebertia.com> writes:

> That is, `True if x else False` conceptually gets compiled down to
> `True if bool(x) == 1 else False` (but without doing a run-time lookup
> of "bool").

It won't look up the *name* ‘bool’, but it will use that object. Any
boolean expression is going to be calling the built-in ‘bool’ type
constructor.

So the answer to the OP's question is no: the function isn't equivalent
to the type, because the OP's ‘bool_equivalent’ function necessarily
uses the built-in ‘bool’ type, while the reverse is not true.

-- 
 \        “Perchance you who pronounce my sentence are in greater fear |
  `\   than I who receive it.” —Giordano Bruno, burned at the stake by |
_o__)  the Catholic church for the heresy of heliocentrism, 1600-02-16 |
Ben Finney

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

#3358

Le 16/04/2011 23:38, Ben Finney a écrit :

> So the answer to the OP's question is no: the function isn't equivalent
> to the type,


Can bool() type and bool_equivalent() function return different values ?


> because the OP's ‘bool_equivalent’ function necessarily
> uses the built-in ‘bool’ type, while the reverse is not true.


The documentation doesn't seem to state it performs this call. I'm 
referring to
-- §5.10 Boolean operations in Document Reference Python 2.7
-- bool()'s description in Library Reference
-- §5.1 Truth Value Testing in Library Reference

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

#3361

On Sat, Apr 16, 2011 at 4:51 PM, candide <candide@free.invalid> wrote:
> Le 16/04/2011 23:38, Ben Finney a écrit :
>
>> So the answer to the OP's question is no: the function isn't equivalent
>> to the type,
>
> Can bool() type and bool_equivalent() function return different values ?

No. The distinction being drawn is rather pedantic, IMO.

>> because the OP's ‘bool_equivalent’ function necessarily
>> uses the built-in ‘bool’ type, while the reverse is not true.
>
> The documentation doesn't seem to state it performs this call.

This is why I used the qualifiers "the equivalent of" and "conceptually".

> I'm referring to
> -- §5.10 Boolean operations in Document Reference Python 2.7
> -- bool()'s description in Library Reference

"bool([x])    Convert a value to a Boolean, using the standard truth
testing procedure."

> -- §5.1 Truth Value Testing in Library Reference

This describes "the standard truth testing procedure". Ideally, this
section would be linked to in bool()'s docs.

Cheers,
Chris
--
http://blog.rebertia.com

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

#3366

candide <candide@free.invalid> writes:

> Le 16/04/2011 23:13, Ben Finney a écrit :
>
> > The ‘bool’ built-in is not a function.
>
> Oops, unfortunate confusion!! but built-in types and built-in
> functions are sometimes so similar from the user's point of view ;)

Yes, intentionally so, because:

> All the same, you can notice that the official documentation describes
> bool() as a built-in function, cf.
> http://docs.python.org/library/functions.html

sometimes functions are replaced by types, or vice versa, and the user
code doesn't have to know.

Sadly, the result can be that the documentation is sometimes out of date
with the implementation :-)


candide <candide@free.invalid> writes:

> Le 16/04/2011 23:38, Ben Finney a écrit :
>
> > So the answer to the OP's question is no: the function isn't
> > equivalent to the type,
>
> Can bool() type and [my example] bool_equivalent() function return
> different values ?

Why do you need to know? (I should have asked that question earlier.)

> > because the OP's ‘bool_equivalent’ function necessarily uses the
> > built-in ‘bool’ type, while the reverse is not true.
>
> The documentation doesn't seem to state it performs this call.

Right, just as APIs that return strings won't explicitly talk about
calling the ‘str’ type constructor. I don't understand why you expect
that.

-- 
 \       “My business is to teach my aspirations to conform themselves |
  `\              to fact, not to try and make facts harmonise with my |
_o__)                   aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney

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

#3378

Le 17/04/2011 04:39, Ben Finney a écrit :

>
> Why do you need to know? (I should have asked that question earlier.)
>


First because I was doubting the true interest of the bool() type. In 
fact, it appears that it's _semantically_ a shortcut for
True if x else False. I could't imagine a builtin function having a so 
trivial implementation. Compare with float() or int(). I also try to 
consider how essential the bool() type is. Again compare with int() or 
str() types.

In the orther hand, I'm builting a sort of documentation for learning 
Python. In order to spell out the purposes of the bool() type, I guessed 
that giving an equivalence code could help.

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

#3381

On Sun, Apr 17, 2011 at 6:38 PM, candide <candide@free.invalid> wrote:
> I also try to consider how essential the bool() type is.
> Again compare with int() or str() types.

Well, of course you can always implement bool as an int; C has done
this for decades, and it hasn't killed it. You can also implement
integers as strings - REXX manages quite well, and gets some
advantages therefrom. But having an explicit bool type has its
benefits too. Essential? No. Useful? Certainly.

Chris Angelico

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

#3440

Chris Angelico wrote:

> Well, of course you can always implement bool as an int;

Which Python used to do once upon a time -- and still does
in a way, because bool is a subclass of int.

The bool type was added mainly to provide a type that prints
out as 'True' or 'False' rather than 1 or 0. This can be
a considerable help for debugging and keeping the conceptual
meaning of one's data clear.

-- 
Greg

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

#3497

On 4/17/2011 5:12 PM, Gregory Ewing wrote:
> Chris Angelico wrote:
>
>> Well, of course you can always implement bool as an int;
>
> Which Python used to do once upon a time -- and still does
> in a way, because bool is a subclass of int.
>
> The bool type was added mainly to provide a type that prints
> out as 'True' or 'False' rather than 1 or 0. This can be
> a considerable help for debugging and keeping the conceptual
> meaning of one's data clear.

    This is typical for languages which backed into a "bool" type,
rather than having one designed in.  The usual result is a boolean
type with numerical semantics, like

 >>> True + True
2

which ought to either generate a TypeError or be interpreted
as "or", but due to the legacy botch, does not.

    Pascal got this right.  (A nice feature of Pascal
was that "packed array of boolean" was a bit array).
C, which originally lacked a "bool" type, got it wrong.
So did Python.  Java is in the middle, with an isolated
"boolean" type but a system that allows casts.
				
				John Nagle

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

#3511

John Nagle wrote:
>    Pascal got this right.  (A nice feature of Pascal
> was that "packed array of boolean" was a bit array).
> C, which originally lacked a "bool" type, got it wrong.
> So did Python.

If Python had had a boolean type from the beginning, it
probably wouldn't have been a subclass of int -- that was
more or less forced by backwards compatibility issues.

> Java is in the middle, with an isolated
> "boolean" type but a system that allows casts.

I'm not sure that's all that much different from Pascal,
where you can use ord() to turn a boolean into an int
if you want to. At least you're being explicit.

-- 
Greg

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

#3517

Am 18.04.2011 21:58, schrieb John Nagle:
>     This is typical for languages which backed into a "bool" type,
> rather than having one designed in.  The usual result is a boolean
> type with numerical semantics, like
> 
>  >>> True + True
> 2

I find the behavior rather useful. It allows multi-xor tests like:

if a + b + c + d != 1:
    raise ValueError("Exactly one of a, b, c or d must be true.")

Christian

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

#3541

On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes <lists@cheimes.de> wrote:
> Am 18.04.2011 21:58, schrieb John Nagle:
>>     This is typical for languages which backed into a "bool" type,
>> rather than having one designed in.  The usual result is a boolean
>> type with numerical semantics, like
>>
>>  >>> True + True
>> 2
>
> I find the behavior rather useful. It allows multi-xor tests like:
>
> if a + b + c + d != 1:
>    raise ValueError("Exactly one of a, b, c or d must be true.")
>

Unless you're sure all of a, b, c, and d are boolean values, an int
with a negative value slipping in could result in the sum equaling 1,
but more than one of the variables evaluating to True in boolean
contexts.

-- 
regards,
kushal

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

#3563

On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes <lists@cheimes.de> wrote:
> Am 18.04.2011 21:58, schrieb John Nagle:
>> ?? ?? This is typical for languages which backed into a "bool" type,
>> rather than having one designed in. ??The usual result is a boolean
>> type with numerical semantics, like
>>
>> ??>>> True + True
>> 2
>
> I find the behavior rather useful. It allows multi-xor tests like:
>
> if a + b + c + d != 1:
> ?? ??raise ValueError("Exactly one of a, b, c or d must be true.")

I guess I never thought about it, but there isn't an 'xor' operator to
go along with 'or' and 'and'.  Must not be something I need very often.

-- 
Grant Edwards               grant.b.edwards        Yow! I am having FUN...
                                  at               I wonder if it's NET FUN or
                              gmail.com            GROSS FUN?

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

#3568

On Apr 19, 10:23 am, Grant Edwards <inva...@invalid.invalid> wrote:
> On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes <li...@cheimes.de> wrote:
> > Am 18.04.2011 21:58, schrieb John Nagle:
> >> ?? ?? This is typical for languages which backed into a "bool" type,
> >> rather than having one designed in. ??The usual result is a boolean
> >> type with numerical semantics, like
>
> >> ??>>> True + True
> >> 2
>
> > I find the behavior rather useful. It allows multi-xor tests like:
>
> > if a + b + c + d != 1:
> > ?? ??raise ValueError("Exactly one of a, b, c or d must be true.")
>
> I guess I never thought about it, but there isn't an 'xor' operator to
> go along with 'or' and 'and'.  Must not be something I need very often.
>

You also can't evaluate xor without evaluating both operands, meaning
there
is never a short-circuit; both and and or can short-circuit, though.
Also
boolean xor is the same as !=.

Jean-Paul

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

#3613

Jean-Paul Calderone wrote:

> Also boolean xor is the same as !=.

Only if you have booleans. Even without short circuiting,
a boolean xor operator could provide the service of
automatically booling things for you (is that a word?).
> 
> Jean-Paul

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

#4233

In article <iok5tg$svv$1@reader1.panix.com>,
Grant Edwards  <invalid@invalid.invalid> wrote:
>
>On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes <lists@cheimes.de> wrote:
>> Am 18.04.2011 21:58, schrieb John Nagle:
>>> ?? ?? This is typical for languages which backed into a "bool" type,
>>> rather than having one designed in. ??The usual result is a boolean
>>> type with numerical semantics, like
>>>
>>> ??>>> True + True
>>> 2
>>
>> I find the behavior rather useful. It allows multi-xor tests like:
>>
>> if a + b + c + d != 1:
>> ?? ??raise ValueError("Exactly one of a, b, c or d must be true.")
>
>I guess I never thought about it, but there isn't an 'xor' operator to
>go along with 'or' and 'and'.  Must not be something I need very often.

There is. <> applied to booleans is xor.

>
>--
>Grant Edwards               grant.b.edwards        Yow! I am having FUN...
>                                  at               I wonder if it's NET FUN or
>                              gmail.com            GROSS FUN?


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#4245

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:

>>I guess I never thought about it, but there isn't an 'xor' operator to
>>go along with 'or' and 'and'.  Must not be something I need very often.
> 
> There is. <> applied to booleans is xor.
> 
Best to get into the habit of using '!=' otherwise you'll find Python 3.x a 
bit frustrating.

However, that only works if you have exactly two values: both 'and' and 
'or' will extend easily to any number of values:

 >>> True and False and True
 False
 >>> False or False or True or False
 True

but using != for 'xor' doesn't extend the same way:

 >>> False != False != True
 False

You can use 'sum(...)==1' for a larger number of values but do have to be 
careful that all of them are bools (or 0|1).

-- 
Duncan Booth http://kupuguy.blogspot.com

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

#3542

On Tue, Apr 19, 2011 at 4:23 PM, Kushal Kumaran
<kushal.kumaran+python@gmail.com> wrote:
>> if a + b + c + d != 1:
>>    raise ValueError("Exactly one of a, b, c or d must be true.")
>>
>
> Unless you're sure all of a, b, c, and d are boolean values, an int
> with a negative value slipping in could result in the sum equaling 1,
> but more than one of the variables evaluating to True in boolean
> contexts.

If they're all expressions, then you can easily guarantee that.

ChrisA

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

#3551

On Tue, 19 Apr 2011 16:26:50 +1000, Chris Angelico wrote:

> On Tue, Apr 19, 2011 at 4:23 PM, Kushal Kumaran
> <kushal.kumaran+python@gmail.com> wrote:
>>> if a + b + c + d != 1:
>>>    raise ValueError("Exactly one of a, b, c or d must be true.")
>>>
>>>
>> Unless you're sure all of a, b, c, and d are boolean values, an int
>> with a negative value slipping in could result in the sum equaling 1,
>> but more than one of the variables evaluating to True in boolean
>> contexts.
> 
> If they're all expressions, then you can easily guarantee that.

*raises eyebrow*


Either of these should do the job:

    sum(map(bool, (a, b, c, d)))

    sum(bool(x) for x in (a, b, c, d))

but I don't see how 

(arbitrary expression) + (another expression) + ... + (last expression)

can have any guarantees applied. I mean, you can't even guarantee that 
they won't raise an exception. Can you explain what you mean?


-- 
Steven

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

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

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

csiph-web