A descriptor instance is shared by every object of its class, so where should per-instance state live?

### Where the object actually lives ```python class Sensor: temp = Celsius() ``` `Celsius()` is evaluated **once**, while the class body runs. One object is created, it is stored in `Sensor.__dict__['temp']`, and every `Sensor` instance that ever exists reaches that same object. Subclasses inherit the very same object unless they rebind the name. So `self` inside its methods identifies the *attribute*, not the object whose attribute is being read. ### The bug this causes ```python class Celsius: def __get__(self, obj, objtype=None): return self.value # shared by every Sensor def __set__(self, obj, value): self.value = float(value) a, b = Sensor(), Sensor() a.temp = 21.0 b.temp = 92.0 a.temp # 92.0 - b's write landed on a ``` In a sensor-telemetry collector this is a nasty failure because it is silent and load-dependent: with one device in the test rig nothing looks wrong, and only once several collectors run concurrently do readings start to smear across devices. Each `__set__` overwrites the single shared slot, so what any object reports is whatever was written last, anywhere in the process. The same shape appears in cache-hit counters and validation bookkeeping kept on the descriptor: with one object per class it looks fine and it never is. ### Fix one: the instance dictionary ```python class Celsius: def __get__(self, obj, objtype=None): if obj is None: return self return obj.__dict__["_temp"] def __set__(self, obj, value): obj.__dict__["_temp"] = float(value) def __delete__(self, obj): obj.__dict__.pop("_temp", None) ``` Now the value lives with the object it describes, dies with it, is visible to `vars(obj)`, pickles with the instance and costs nothing extra. The key subtlety is that this only works cleanly for a **data** descriptor: because the class defines `__set__`, `__get__` is still consulted before the instance dictionary, so it retains control even though the data now sits there. A *non-data* descriptor that wrote under its own attribute name would be shadowed from the second read onward — which is a deliberate caching technique, not this pattern. Hardcoding a key like `"_temp"` is only acceptable for a one-off; a reusable descriptor must derive the key from the attribute name it was assigned to, which is what the name-capture hook fired at class creation exists for. Whatever key you choose, it must be **unique per descriptor**, or two attributes managed by the same descriptor class collide on one storage slot — a second, quieter version of the same bug. And the key must not be one you also expose as a public attribute, or callers can bypass validation by writing to it directly. Write `obj.__dict__[key] = ...` rather than `setattr(obj, key, ...)`: if the key ever equals the managed name, `setattr` re-enters `__set__` and recurses until the stack blows. ### Fix two: a weak-keyed side table If the owner class defines `__slots__` there is no instance dictionary to write into, and the same is true for many C-implemented types. Then use `weakref.WeakKeyDictionary` keyed on the instance, so entries disappear when the object does. The constraints are real: the instances must be hashable and weak-referenceable, and a class that defines `__eq__` without `__hash__` is unhashable, so this silently excludes exactly the value-like classes people most want to attach descriptors to. It is also slower than a dictionary write and, under free-threading, needs the same care as any other shared mapping. A third option exists for slotted classes: give the descriptor a *companion slot* in the owner's `__slots__` and store through it. That trades generality for speed and keeps everything on the instance. ### The concurrency angle Because one descriptor object serves the whole process, any mutable state you deliberately keep on it — counters, caches, a lazily built converter table — is shared across every thread touching any instance. Under the free-threaded build officially supported since 3.14, that state has no GIL to serialise updates, so read-modify-write bookkeeping on a descriptor needs its own lock. Per-instance storage sidesteps the question for the values themselves, which is one more reason to prefer it. ### How to spot it in review Any assignment to `self.<something>` inside `__set__` or `__get__` that is not read-only configuration set up in `__init__` is the smell. Configuration — a limit, a unit, a validator function — is exactly what *should* live on the descriptor, because it genuinely is per attribute. Values are exactly what should not.