Reference Tracking

[Alex Martelli]

Matt Bergin wrote:

> Alex Martelli wrote:
>> Matt Bergin wrote:
>>    ...
>>>I'm just worried that if an exception occurs in a thread then the cursor
>>>will never be returned, using the 'no black magic' method which appeals
>>>to me the most. Could I prevent this by careful use of try: finally?
> 
>> Yes.  And you can *in addition* keep the cursors you've handed out
>> in a list and ALSO periodically do the scan checking refcounts just
>> to help you debug user threads that aren't returning cursors properly
>> (or use other tricks as above but for debugging-help rather than
>> functional purposes).
> 
> Just out of interest, when I run a very simple script, i.e.
> 
> import sys
> a=1
> print sys.getrefcount(a)
> 
> Why is the refcount of a so high (50 from the command line)? Where are
> these references lurking? Should I check be checking for changes in the
> refcount of an object rather than its absolute value?

Python can cache any immutable objects for performance reasons.
In practice, Python does such caching for small integers, and 1
is clearly a popular value -- any number of system-maintained
data structures may have attributes and items that happen to
be worth 1 (or 0, or other small, popular numbers).

import gc
gc.get_referrers(1)

will at any time give you a list of all containers which have
a reference to the value 1, if you're curious.  Of course, having
such a container in hand will not necessarily make it easy to
understand WHAT the container in fact IS -- but many will be
dicts with string keys, which lets you do some detective work;-).


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...).


In your case, you were talking about tracking objects of a specific
different type -- not ones that Python will implicitly cache and
reuse, such as small integers.  Thus, you do not necessarily need
to work with _changes_ in refcounts rather than with refcounts
directly -- I think using the refcounts directly may be simpler.


Alex