On Fri, Apr 12, 2013 at 1:36 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On 12/04/13 12:53, Amit Saha wrote: > >> So for example: >> >>>>> a=1 >>>>> b=1 >>>>> a is b >> >> True >>>>> >>>>> id(a) == id(b) >> >> True > > > > This is not a very good example, because that behaviour itself is > implementation-dependent and not guaranteed. For example, in IronPython 2.6 > I get completely different behaviour: > >>>> a = 1 >>>> b = 1 >>>> a is b > > False >>>> >>>> print id(a), id(b) > > 43 44 > > > Even in CPython, the implementation you are probably using, the behaviour > will depend on all sorts of factors, such as the type of the object, and > even the value: > > py> a = 10001 > py> b = 10001 > py> a is b > False > > py> a = 1.0 > py> b = 1.0 > py> a is b > False > > > > > >> So, when are identifiers same and when not? That >> depends on the type of object - mutable or immutable. > > > No, not really. The best you can say is this: > > If Python has a choice between creating a new object, and re-using an > existing object, and the object is mutable, Python will never re-use the > object since that might introduce bugs. If the object is immutable, Python > *may* re-use it, or it may not.
Indeed. My point was to give the original poster at least *some* idea of what the issue really is. If he/she takes that hint and experiments, reads the Python data model, and finds something weird with that statement - he/she will discover the finer/exactly correct details. So, thanks for clarifying this. > > > When does Python have a choice between re-using existing objects? That's a > complicated question, and there's no straightforward answer. The best I can > do is give some examples: > > > # References to a name will ALWAYS use the same object: > x is x # always True > > > # References to another identifier MIGHT re-use the same object: > x.attr is x.attr # sometimes True, sometimes False > x[index] is x[index] # the same > > > # References to a literal MIGHT re-use the same object, if it is immutable: > 'x' is 'x' # might be True > ['x'] is ['x'] # always False > > > # The same literal on the same line of code MIGHT be re-used: > x = 123.5; y = 123.5; x is y # might be True > > # ...even if they aren't re-used when on separate lines. > x = 123.5 > y = 123.5 > x is y # probably will be False > > > # If two or more identifiers are assigned to a value at the same time, > # Python GUARANTEES to use the same object: > x = y = anything_you_like() > x is y # always True > > > # Assignment in general never makes a new object: > x = something() > y = x > x is y # always True[1] > > > Object identity is almost never important. About the only time it is > important is when comparing things to None. > > But in practice, you can expect (but not rely on!) CPython to re-use the > following: > > * Small integers. Which values count as small depend on the version, but -1 > to 100 is common. > > * Strings that look like identifiers, e.g. "x", "item", but not "hello > world" or "?". The link to the SO question discusses string interning to some detail. > > But don't rely on this, as it is not guaranteed and could go away at any > time. Yes, the 'is' check shouldn't really be relied on checks such as those for None objects. -Amit. -- http://amitsaha.github.com/ _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
