4 ms·

Nope; that's a common misconception. >>> "1"1000 is "1"1000 False >>> 231 is 231 False The fact is that the only thing guaranteed by "is" is

by devinj 16y ago

Nope; that's a common misconception. >>> "1"*1000 is "1"*1000 False >>> 2**31 is 2**31 False The fact is that the only thing guaranteed by "is" is that if you have "a = b", then "a is b". Whether or not "new" objects are going to be identical to old ones is left undefined, and may change depending on type or value.

jacobolus 16y ago
Sure. `==` should be used for such comparisons, not `is`, as the latter is semantically different. They have the same effect for "apricot" because Python interns strings up to length 20: >>> "1"*20 is "1"*20 True >>> "1"*21 is "1"*21 False
lubutu 16y ago
that is very confusing, but fair enough. it at least seems to work in the sample code.
- lubutu 16y ago
  fine fine, i've changed the code slightly. sometimes i wonder whether i am too imprecise for a programmer. :o
- devinj 16y ago
  Well, "is" in Python is a specific notion of object identity, and Python happens to sometimes decide it's not worth creating new objects. Not really confusing, it's just completely different from '==' (except by coincidence basically).
- jerf 16y ago
  "==" is an equality check that calls various methods[1] to answer the question. "is" is true if and only if the two references are actually the exact same reference, or, under the hood, basically that the two pointers are equal. >>> [1,2,3] == [1,2,3] True >>> [1,2,3] is [1,2,3] False The equality check in the case of lists is recursive and checks the equality of its elements piecewise. But they are two different lists, so they don't check "is" the same. As an optimization, because everything in Python is an object (despite occasional claims to the contrary by the Ruby community), certain objects are created at interpreter start time and cached forever, such as (IIRC) the numbers 0 through 100 or so, so if you happen to use "is" it will sometimes "work": >>> (1 + 3) is (2 + 2) True but it's not good or reliable: >>> (1000 + 3000) is (2000 + 2000) False Basically, unless you are doing something with "object identity" and you know what you are doing (and if you don't know what I mean by caring about "object identity" you probably don't pass this check), OR are checking that something is specifically "None" and not merely false (as None is another of those cached values and there is only ever one None in the system), don't use "is". [1]: http://docs.python.org/reference/expressions.html#notin http://docs.python.org/reference/expressions.html#notin

Nope; that's a common misconception. >>> "1"*1000 is "1"*1000 False >>> 2**31 is 2**31 False The fact is that the only thing guaranteed by "is" is

by devinj 16y ago

jacobolus 16y ago

Sure. `==` should be used for such comparisons, not `is`, as the latter is semantically different. They have the same effect for "apricot" because Python interns strings up to length 20: >>> "1"*20 is "1"*20 True >>> "1"*21 is "1"*21 False

lubutu 16y ago

that is very confusing, but fair enough. it at least seems to work in the sample code.

lubutu 16y ago
fine fine, i've changed the code slightly. sometimes i wonder whether i am too imprecise for a programmer. :o
devinj 16y ago
Well, "is" in Python is a specific notion of object identity, and Python happens to sometimes decide it's not worth creating new objects. Not really confusing, it's just completely different from '==' (except by coincidence basically).
jerf 16y ago
"==" is an equality check that calls various methods[1] to answer the question. "is" is true if and only if the two references are actually the exact same reference, or, under the hood, basically that the two pointers are equal. >>> [1,2,3] == [1,2,3] True >>> [1,2,3] is [1,2,3] False The equality check in the case of lists is recursive and checks the equality of its elements piecewise. But they are two different lists, so they don't check "is" the same. As an optimization, because everything in Python is an object (despite occasional claims to the contrary by the Ruby community), certain objects are created at interpreter start time and cached forever, such as (IIRC) the numbers 0 through 100 or so, so if you happen to use "is" it will sometimes "work": >>> (1 + 3) is (2 + 2) True but it's not good or reliable: >>> (1000 + 3000) is (2000 + 2000) False Basically, unless you are doing something with "object identity" and you know what you are doing (and if you don't know what I mean by caring about "object identity" you probably don't pass this check), OR are checking that something is specifically "None" and not merely false (as None is another of those cached values and there is only ever one None in the system), don't use "is". [1]: http://docs.python.org/reference/expressions.html#notin http://docs.python.org/reference/expressions.html#notin