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):
False


This is really obscur to me...

 

[Diez B. Roggisch]

l = []

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

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

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.

 

[Duncan Booth]

Hi there !

Can someone explain me the following behaviour ?

l = []
0 in (l is False)

Traceback (most recent call last):
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]

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.

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

 

[Laszlo Zsolt Nagy]

(0 in l) is False
This gives me the same exception.
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument required

Did you really try these examples?


Best,

Laci

mailto:[email protected]
web:http://designasign.biz

 

[Laszlo Zsolt Nagy]

This gives me the same exception.
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:[email protected]
web:http://designasign.biz

 

[Richard Brodie]

Did you really try these examples?

False

 

[Paul Robson]

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

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

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]

Hi there !

Can someone explain me the following behaviour ?

l = []
0 in (l is False)

Traceback (most recent call last):

True

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]

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

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

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]

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