Velocity Reviews > [False,True] and [True,True] --> [True, True]?????

# [False,True] and [True,True] --> [True, True]?????

bdb112
Guest
Posts: n/a

 04-20-2009
Is there any obvious reason why
[False,True] and [True,True]
gives [True, True]

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)]

Andre Engels
Guest
Posts: n/a

 04-20-2009
On Mon, Apr 20, 2009 at 9:03 AM, bdb112 <(E-Mail Removed)> wrote:
> Is there any obvious reason why
> [False,True] and [True,True]
> gives [True, True]

Well, whether the reason is obvious, I do not know, but the way and
seems to be implemented is:

X and Y =
* X if the boolean value of X is false
* Y if the boolean value of X is true

In this case, bool([False,True]) = true, so the second element is taken.

--

AggieDan04
Guest
Posts: n/a

 04-20-2009
On Apr 20, 2:03*am, bdb112 <(E-Mail Removed)> wrote:
> Is there any obvious reason why
> [False,True] and [True,True]
> gives [True, True]
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)]

X and Y == (Y if X else X)
X or Y == (X if X else Y)

[False, True] is true, so the and operator returns the second argument.

Gabriel Genellina
Guest
Posts: n/a

 04-20-2009
En Mon, 20 Apr 2009 04:03:28 -0300, bdb112 <(E-Mail Removed)>
escribió:

> Is there any obvious reason why
> [False,True] and [True,True]
> gives [True, True]

Yes: short-circuit evaluation.
[False,True] and [True,True] is *not* an element-by-element operation,
it's a simple expression involving two objects (two lists).
A and B means: check the boolean value of A; if it's false, return A.
Else, return B.
A non-empty list has a boolean value of true, so the second list is
returned.

If you want an element-wise operation:
A = [False,True]
B = [True,True]
result = [a and b for a,b in zip(A,B)]
--
Gabriel Genellina

bdb112
Guest
Posts: n/a

 04-20-2009
THanks Gabriel,
Now I know about the zip function.

Your explanation of Boolean ops on lists was clear.
It leads to some intriguing results:

bool([False])
--> True

I wonder if python 3 changes any of this?

> A and B means: check the boolean value of A; if it's false, return A. *
> Else, return B.
> A non-empty list has a boolean value of true, so the second list is *
> returned.
>
> If you want an element-wise operation:
> A = [False,True]
> B = [True,True]
> result = [a and b for a,b in zip(A,B)]
> --
> Gabriel Genellina

Peter Otten
Guest
Posts: n/a

 04-20-2009
bdb112 wrote:

> Your explanation of Boolean ops on lists was clear.
> It leads to some intriguing results:
>
> bool([False])
> --> True
>
> I wonder if python 3 changes any of this?

No. Tests like

if items:
...

to verify that items is a non-empty list are a widespread idiom in Python.
They rely on the behaviour you observe.

Peter

Gerhard Häring
Guest
Posts: n/a

 04-20-2009
Peter Otten wrote:
> bdb112 wrote:
>
>> Your explanation of Boolean ops on lists was clear.
>> It leads to some intriguing results:
>>
>> bool([False])
>> --> True
>>
>> I wonder if python 3 changes any of this?

>
> No. Tests like
>
> if items:
> ...
>
> to verify that items is a non-empty list are a widespread idiom in Python.
> They rely on the behaviour you observe.

Are they widespread? I haven't noticed, yet.

I prefer to write it explicitly:

if len(lst) > 0:
...

if item is None:
...

etc.

-- Gerhard

Chris Rebert
Guest
Posts: n/a

 04-20-2009
On Mon, Apr 20, 2009 at 1:54 AM, Gerhard HÃ¤ring <(E-Mail Removed)> wrote:
> Peter Otten wrote:
>> bdb112 wrote:
>>
>>> Your explanation of Boolean ops on lists was clear.
>>> It leads to some intriguing results:
>>>
>>> bool([False])
>>> --> True
>>>
>>> I wonder if python 3 changes any of this?

>>
>> No. Tests like
>>
>> if items:
>> Â* Â*...
>>
>> to verify that items is a non-empty list are a widespread idiom in Python.
>> They rely on the behaviour you observe.

>
> Are they widespread? I haven't noticed, yet.
>
> I prefer to write it explicitly:
>
> if len(lst) > 0:

Nope, that's not idiomatic. The simpler `if lst:` version is indeed widespread.

> Â* Â*...
>
> if item is None:

That's pretty common and accepted; comparison to None is something of
a special case.

Cheers,
Chris
--
I have a blog:
http://blog.rebertia.com

Peter Otten
Guest
Posts: n/a

 04-20-2009
Gerhard HÃ¤ring wrote:

> Peter Otten wrote:
>> bdb112 wrote:
>>
>>> Your explanation of Boolean ops on lists was clear.
>>> It leads to some intriguing results:
>>>
>>> bool([False])
>>> --> True
>>>
>>> I wonder if python 3 changes any of this?

>>
>> No. Tests like
>>
>> if items:
>> ...
>>
>> to verify that items is a non-empty list are a widespread idiom in
>> Python. They rely on the behaviour you observe.

>
> Are they widespread? I haven't noticed, yet.

That is my impression.

> I prefer to write it explicitly:
>
> if len(lst) > 0:
> ...

matches search expression
ca. 1000 langython "if items:"
216 langython "if len(items) > 0:"

This could of course mean that "people who like 'items' as a list name also
like the 'if items:...' idiom" or "'items' is a popular name for boolean
values" or "the search result is spammed by a gazillion zope versions"...

Peter

Steven D'Aprano
Guest
Posts: n/a

 04-20-2009
On Mon, 20 Apr 2009 10:54:40 +0200, Gerhard HÃ¤ring wrote:

> Peter Otten wrote:
>> bdb112 wrote:
>>
>>> Your explanation of Boolean ops on lists was clear. It leads to some
>>> intriguing results:
>>>
>>> bool([False])
>>> --> True
>>>
>>> I wonder if python 3 changes any of this?

>>
>> No. Tests like
>>
>> if items:
>> ...
>>
>> to verify that items is a non-empty list are a widespread idiom in
>> Python. They rely on the behaviour you observe.

>
> Are they widespread? I haven't noticed, yet.
>
> I prefer to write it explicitly:
>
> if len(lst) > 0:

Do you also count the length of a list explicitly?

n = 0
for item in lst:
n += 1
if n > 0:
...

No? Of course you don't. You understand that lists know how to calculate
their own length, and you just ask the list for its length. Great.

Well, lists also know whether or not they are empty, without needing to
concern yourself with the definition of "empty".

if lst:
# not empty
else:
# empty

All Python objects have an understanding of "empty" or "not empty", and
the only time I've seen it cause problems is with iterators, because you
can't tell if an iterator is empty until you actually try to access a
value.

> if item is None:
> ...

That's a completely different test. That's testing whether item is the
specific singleton None. It is very different from testing bool(item).

--
Steven