From: Gabriel Genellina on 9 Aug 2010 16:14 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 9 Aug 2010 17:13 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 9 Aug 2010 21:18 "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 10 Aug 2010 05:19 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 12 Aug 2010 22:52
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. |