What does weakref.ref give you that an ordinary Python reference does not?

**A weak reference is a reference that does not get a vote on whether the object stays alive.** CPython destroys an object when the number of *strong* references to it reaches zero. Every ordinary name binding, every list element, every dict value, every attribute and every argument sitting on the call stack is a strong reference, and while even one of them exists the object cannot be reclaimed. `weakref.ref(obj)` builds a small separate object that points at `obj` **without** joining that population. When the last strong reference disappears, `obj` is destroyed exactly as if the weak reference had never been created, and the weak reference becomes *dead*. ### Reading through one A `weakref.ref` is callable with no arguments. It returns the referent, or `None` if the referent is gone: ```python import weakref r = weakref.ref(session) obj = r() if obj is None: ... # it is already gone else: obj.charge() ``` That `None` return is the entire safety story. There is deliberately no separate `is_alive()` you can consult and then act on, because between the check and the use the object could die. The correct idiom is the one above: call the ref **once**, bind the result to a local name — that local is itself a strong reference, so the object is now pinned for as long as the local lives — and only then test it against `None`. ### ref versus proxy `weakref.proxy(obj)` wraps the same machinery in a transparent object: attribute access, indexing and operators are forwarded to the referent, so most code cannot tell it is holding a proxy. When the referent is dead, using the proxy raises `ReferenceError` instead of quietly returning `None`. The tradeoff is that proxies are **not hashable**, so a proxy cannot be a dict key or a set member, and `is` comparisons against the real object fail. Prefer `weakref.ref` when you want the holder to be explicit about the weakness or you need hashing; prefer `weakref.proxy` when you are handing the object to code that should not know. ### Callbacks Both `weakref.ref` and `weakref.proxy` take an optional second argument: a callable invoked with the (now dead) weak reference once the referent is collected. The classic bug is a callback that closes over the referent — that closure is a strong reference, so the object never dies and the callback never runs. A callback must capture only the data it needs, never the object itself. `weakref.finalize` is the friendlier wrapper over the same mechanism. ### Not everything can be weakly referenced A type supports weak references only if its instances carry a `__weakref__` slot. Instances of classes written in Python get one for free. Many builtins do not: `weakref.ref([1, 2])` raises `TypeError: cannot create weak reference to 'list' object`, and the same applies to `dict`, `tuple`, `int`, `str`, `bytes` and a bare `object()`. Functions, classes, modules, `set` and `frozenset` *are* weak-referenceable. Two escape hatches exist: subclass the builtin (instances of `class Basket(list): pass` are weak-referenceable), or, if you use `__slots__`, add `'__weakref__'` to the slots tuple, because declaring `__slots__` otherwise removes the slot. ### Where it earns its keep Three shapes recur. **Registries and caches** that must not be the reason an object survives — a mapping from an id to a live object where the mapping is a convenience, not an owner. **Observer lists**, so subscribing to an event source does not immortalise the subscriber. **Back-pointers**: a child holding a strong reference to its parent while the parent holds its children creates a reference cycle that plain counting cannot free, and making the child-to-parent link weak breaks the cycle at the design level rather than leaving it to the collector. ### What it is not A weak reference does not make an object die *sooner*; the object dies when the last strong reference goes, and taking a weak one changes nothing about that moment. It is not a cache-eviction policy — it evicts on the whims of your program's ownership, not on size or age. And it is not a substitute for releasing external resources deterministically: a socket or a file should be closed by a `with` block, not left to the moment some referent happens to be collected. Weak references are about *object lifetime*, and the discipline they impose is that somebody, somewhere, must still own the object strongly — otherwise it evaporates the instant you look away.