weird behaviour of "0 in [] is False"

[Sylvain Thenault]

Hi there !

Can someone explain me the following behaviour ?

l = []
0 in (l is False) Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required (0 in l) is False True 0 in l is False

False
This is really obscur to me...

--
Sylvain Thénault LOGILAB, Paris (France).

http://www.logilab.com http://www.logilab.fr http://www.logilab.org

[Diez B. Roggisch]

>>>> l = []

0 in (l is False) Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required

that should be clear - 0 in False can't work.

(0 in l) is False True 0 in l is False

False

It seems to stem from a behaviour python exhibits in expressions like this:

3 > 2 > 1

This yields True, while

(3 > 2 ) > 1

yields false. Chaining of operators gets translated like this:

3 > 2 and 2 > 1

Look in section 5.9 of the language reference.

Then your expression gets translated to:

0 in l and l is False

which yields False of course.
--
Regards,

Diez B. Roggisch

[Duncan Booth]

Sylvain Thenault wrote:

Hi there !

Can someone explain me the following behaviour ?

l = []
0 in (l is False) Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required (0 in l) is False True 0 in l is False

False
This is really obscur to me...

From the language reference (5.9 Comparisons):
comparison ::= or_expr ( comp_operator or_expr )*
comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "<>" | "!="
| "is" ["not"] | ["not"] "in"

...snip...

Formally, if a, b, c, ..., y, z are expressions and opa, opb, ..., opy
are comparison operators, then a opa b opb c ...y opy z is equivalent
to a opa b and b opb c and ... y opy z, except that each expression is
evaluated at most once.

In other words '0 in l is False' is equivalent to '0 in l and l is False'.

[Sylvain Thenault]

On Tue, 30 Nov 2004 14:18:30 +0100, Diez B. Roggisch wrote:

> l = []
> 0 in (l is False)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required

that should be clear - 0 in False can't work.

yes, I forget to mention that it was the third expression which was
bugging me.

> (0 in l) is False

True

> 0 in l is False

False

It seems to stem from a behaviour python exhibits in expressions like
this:

3 > 2 > 1

This yields True, while

(3 > 2 ) > 1

yields false. Chaining of operators gets translated like this:

3 > 2 and 2 > 1

Look in section 5.9 of the language reference.

Then your expression gets translated to:

0 in l and l is False

which yields False of course.

thanks, I had missed this part of the language reference !
Not yet found an misbehaviour in python... ;)

--
Sylvain Thénault LOGILAB, Paris (France).

http://www.logilab.com http://www.logilab.fr http://www.logilab.org

[Laszlo Zsolt Nagy]

>>>>>> (0 in l) is False

True
This gives me the same exception.
0 in 1

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required

Did you really try these examples?
Best,

Laci

mailto:ga*****@geochemsource.com
web:http://designasign.biz

[Laszlo Zsolt Nagy]

Tuesday, November 30, 2004, 3:15:27 PM, you wrote:

>>> (0 in l) is False
True

This gives me the same exception. 0 in 1

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required

Sorry, It was 0 in l, not 0 in 1. :-)
My fault.
Best, Laci

mailto:ga*****@geochemsource.com
web:http://designasign.biz

[Richard Brodie]

"Laszlo Zsolt Nagy" <ga*****@geochemsource.com> wrote in message
news:ma**************************************@pyth on.org...

Did you really try these examples?

l is 1

False

[Paul Robson]

Sylvain Thenault wrote:

l = []
0 in (l is False)
(l is False) is not a tuple or list, it's a boolean value.

Traceback (most recent call last):
File*"<stdin>",*line*1,*in*?
TypeError: iterable argument required

(0 in l) is False

True

0 in l is False becuase l is empty, so it's False is False which is true,
(except in Intercal probably and Visual C++)
0 in l is False

False

l is False is False because l is not the value false though it has a false
value (err.....)

Okay.

l != False because it's not the displayed value false

but if not l would evaluated to true because [] is a false equivalent.

0 in False .... okay.... this should be an error ..... something to do with
the equivalence confusion of what False is ?

[Scott David Daniels]

Sylvain Thenault wrote:

Hi there !

Can someone explain me the following behaviour ?

l = []
0 in (l is False)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required
(0 in l) is False
True
0 in l is False

False
This is really obscur to me...

A suggestion:
When discussing things on the newsgroup (and in your code), avoid
symbols like "l" and "O" -- they look too much like numbers. Picking
an actual name is best (but depends on your application context).
Second best are names like: "lst", "obj", ...: often, however, such
names are necessary when discussing abstract code properties.

-Scott

[John Roth]

"Paul Robson" <au******@autismuk.muralichucks.freeserve.co.uk> wrote in
message news:co**********@news8.svr.pol.co.uk...

Sylvain Thenault wrote:

> l = []
> 0 in (l is False)
(l is False) is not a tuple or list, it's a boolean value.

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required

> (0 in l) is False True

0 in l is False becuase l is empty, so it's False is False which is true,
(except in Intercal probably and Visual C++)
0 in l is False

False

l is False is False because l is not the value false though it has a false
value (err.....)

Okay.

l != False because it's not the displayed value false

but if not l would evaluated to true because [] is a false equivalent.

0 in False .... okay.... this should be an error ..... something to do
with
the equivalence confusion of what False is ?

It's not an error. As one of the first responders said, check
the language definition. That defines both 'in' and 'is'
as equality operators, and defines exactly what a chain
of equality operators means.

In this case, it means:

(0 in l) and (l is False)

The and short circuits, giving the result of False without
ever doing the final comparison.

Granted, that's not exactly obvious...

John Roth

[Paul Robson]

John Roth wrote:

It's not an error. As one of the first responders said, check
the language definition. That defines both 'in' and 'is'
as equality operators, and defines exactly what a chain
of equality operators means.

In this case, it means:

(0 in l) and (l is False)

The and short circuits, giving the result of False without
ever doing the final comparison.

Granted, that's not exactly obvious...

Thanks ; you learn something every day :)