From: Gabriel Genellina on
En Mon, 09 Aug 2010 08:41:23 -0300, saeed.gnu <saeed.gnu(a)gmail.com>
escribi�:

> "x is y" means "id(y) == id(y)"
> "x is not y" means "id(x) != id(x)"

No; consider this:


py> id([])==id([])
True
py> [] is []
False

Comparing id's is the same as using the is operator only if you can
guarantee that both operands are alive at the same time.


--
Gabriel Genellina

From: Michael Torrie on
On 08/09/2010 06:11 AM, saeed.gnu wrote:
> On Aug 9, 3:41 pm, "saeed.gnu" <saeed....(a)gmail.com> wrote:
>> "x is y" means "id(y) == id(y)"
>> "x is not y" means "id(x) != id(x)"
>> "x is not None" means "id(x) != id(None)"
>>
>> "x is not None" is a really silly statement!! because id(None) and id
>> of any constant object is not predictable! I don't know whay people
>> use "is" instead of "==". you should write "if x!=None" instead of "x
>> is not None"
>
> Although small objects are unique in the memory (with a unique id) and
> using "is" works ok, but that's not logical to compare id's when we
> actually want to compare values!

Sounds like you're confusing Python's namespace with variables. When I say:

a = None

I'm binding the None object to the a name. Thus a *is*
None. While in theory "None" does have a value, doing "a is None" is
much more explicit and clearer than "a == None" although perhaps the
result is the same. In any event "a is None" is actually logical
because that's what I'm normally interested in. Whether or not a is
None. I don't really care about the value of None.




From: Ben Finney on
"saeed.gnu" <saeed.gnu(a)gmail.com> writes:

> "x is y" means "id(y) == id(y)"
> "x is not y" means "id(x) != id(x)"
> "x is not None" means "id(x) != id(None)"

No, the meanings are different. The behaviour might, or might not, be
the same. The operators are different *because* the meanings are
different.

> "x is not None" is a really silly statement!! because id(None) and id
> of any constant object is not predictable!

The value returned from 'id' is not predictable; but it doesn't need to
be predictable. It merely needs to obey the invariant that the identity
of any given object won't change during the object's lifetime.

--
\ “You've got the brain of a four-year-old boy, and I'll bet he |
`\ was glad to get rid of it.” —Groucho Marx |
_o__) |
Ben Finney
From: Jean-Michel Pichavant on
Ben Finney wrote:
> Peter Pearson <ppearson(a)nowhere.invalid> writes:
>
>
>> Hey, that's a cute example, but . . . what a trap! Is it possible to
>> document the use-the-object-not-the-string requirement loudly enough
>> that people won't get caught?
>>
>
> Don't use strings for such values. The data isn't going to be used, so
> there's no sense using a semantically rich data type like a string.
>
> Instead, use an 'object' instance; then, the only way to get a binding
> that will compare equal is to use the very object itself.
>
> FORWARD = object()
> BACKWARD = object()
>
>
Strings may have their use, most of the time providing a string
representation of the object, here is an example:

FORWARD = object()

print 'moving %s' % FORWARD
> moving <object object at 0xb7dab5a8>

Another approach using strings:

class Direction:
FORWARD = 'forward'

print "moving %s' % Direction.FORWARD
> moving forward

Note that
Direction.FORWARD is Direction.FORWARD
is safe and will return True.

JM




From: Matt Schinckel on
On Aug 6, 8:15 am, "Rhodri James" <rho...(a)wildebst.demon.co.uk> wrote:
> On Thu, 05 Aug 2010 17:07:53 +0100, wheres pythonmonks  
>
> <wherespythonmo...(a)gmail.com> wrote:
> > Well, I am not convinced of the equivalence of not None and true:
[snip]
> >>> "spam, eggs, chips and spam" is "spam, eggs, chips and spam"
> True
> >>> a = "spam, eggs, chips and spam"
> >>> b = "spam, eggs, chips and spam"
> >>> a is b
> False

but:

>>> a = "hello"
>>> b = "hello"
>>> a is b
True

Ooh, that looks dangerous. Are they the same object?

>>> a += "o"
>>> a
'helloo'
>>> b
'hello'

Phew.

(Python does not make two copies of small strings until it needs to).

Matt.