Reference Tracking

[Steve Holden]

"Alex Martelli" <aleax at aleax.it> wrote ...
> Ganesan R wrote:
>
> >>>>>> "Alex" == Alex Martelli <aleax at aleax.it> writes:
> >
> >> Note that any Python function call always passes VALUES -- i.e.
> >> there is no difference between your call to sys.getrefcount in
> >> the above snippet and one that directly does sys.getrefcount(1).
> >> In either case, it's the VALUE (1) that you're asking info about;
> >> it makes no difference HOW you obtain the value to pass (I guess
> >> this is probably already clear to you, but, just in case...).
> >
> > Then, I find this confusing
> >
[source of confusion snipped along with 2.2 example]
>
> [alex at lancelot ox]$ python2.3
> Python 2.3a2+ (#11, Mar 28 2003, 12:17:11)
> [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> a='hello world'
> >>> b='hello world'
> >>> id(a), id(b), id('hello world')
> (1076642784, 1076642864, 1076643144)
> >>>
>
> In 2.2, we see Python using different copies of the literal string
> value in all three cases.  In 2.3, we see indications of a different
> strategy -- one value (object, identity, copy, call it as you wish)
> is being used for the first two occurrences, a distinct one for the
> third occurrence.  Strictly issues of optimization strategies on
> the part of different Python implementations, no more.
>
Just in case somebody comes across this message out of context and wonders
what on Earth you're talking about, I feelI should point out that the
Martellibot has here made an uncharacteristic mistake and assumed that
1076642784 == 1076642864, which in most universes is incorrect.

>
> Keep in mind that EQUALITY and IDENTITY are different concepts.  For
> immutables, equality is what you generally care about -- identity is
> shifty and implementation-dependent since such optimizations are
> permissible.  Thus, you shouldn't test "a is b" nor "a is 'hello world'",
> but rather you should use the == (equality check) operator in lieu
> of the is (identity check) operator for such tests.
>
> References are to specific values (specific objects, specific identities,
> specific copies, call them as you wish), thus all considerations about
> reference tracking need to keep this concept in mind.
>
>
> One last indication (not playing a role here, but you're sure to run
> into this as you play with id and the like...): id(...) is unique
> as long as an object exists, but as soon as the object is destroyed,
> its identity may be reused.  So, don't get tricked by such artefacts
> as the following:
>
> [alex at lancelot ox]$ python2.2
> Python 2.2.2 (#1, Oct 24 2002, 11:43:01)
> [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> id('hello world')
> 135683352
> >>> id('hello world')
> 135682152
> >>> id('hello world')
> 135683192
> >>> id('hello world')
> 135683352
> >>> id('hello world')
> 135682736
> >>>
>
> it may SEEM like the first and fourth literals use the same value,
distinct
> from the 2nd and 3rd and 5th -- but they don't -- the first one has been
> destroyed, and happens to get recycled, at the time you create the 4th (in
> other builds you'll no doubt get different results for this -- in 2.2, the
> allocator used is more system-dependent than in 2.3).
>
And the rest is just as true as it always was: I fell into this trap writing
a web server, where a form instance contained its id() value when
represented in HTML to try to trap incorrect submissions. Took me a while to
work out why the id() values were being repeated!

>
> Morals: don't care too deeply about identity of immutables...
>
That's only one moral.

nitpicking-ly y'rs  - steve
--
Steve Holden                                  http://www.holdenweb.com/
How lucky am I?      http://www.google.com/search?q=Steve+Holden&btnI=1
Python Web Programming                 http://pydish.holdenweb.com/pwp/