CPython: the object and data model

In CPython every value, an integer, a function, a class, even a module, is a PyObject living on the heap. At minimum each one carries two fields: a type pointer (ob_type) saying what it is, and a reference count (ob_refcnt) tracking how many references point at it.

x = 1000
type(x)              # <class 'int'>
id(x)                # heap address of the object
import sys
sys.getrefcount(x)   # how many references point here

There are no primitives sitting on the stack the way there are in C or Java. 1000 is a full heap object with a header. This uniformity is the reason you can put anything in a list, pass anything to a function, and (if its type allows) give anything attributes.

A variable is a name bound to an object, not a box holding a value. Assignment never copies; it points a name at an object.

a = [1, 2, 3]
b = a          # a and b name the SAME list
b.append(4)
a              # [1, 2, 3, 4]  mutated through b

Rebinding a name (a = something_else) moves only that one name; it never touches the object or other names. This is why the classic mutable-default-argument bug bites: the default object is built once, at definition time, and shared across calls.

def add(x, bucket=[]):   # created ONCE
    bucket.append(x)
    return bucket
add(1); add(2)           # [1, 2], the same list twice

The fix is bucket=None, then if bucket is None: bucket = [] inside.

== asks are these equal by calling __eq__. is asks are these the same object by comparing identity. They usually agree, but not always.

a = 'hello world'
b = 'hello world'
a == b     # True (same characters)
a is b     # may be True or False

x = 257; y = 257
x is y     # often False

CPython interns small integers (-5 to 256) and many short strings, so identical literals can share one object and is returns True by accident. Outside that range you get distinct objects. Rule: never use is for value comparison, only for singletons like None (x is None). And if you define __eq__, define __hash__ too, or instances become unhashable and unusable as dict keys or set members.

An object's behavior comes from special methods (dunders) on its type, not from the interpreter special-casing values. len(x) calls type(x).__len__(x); x[k] calls __getitem__; for i in x calls __iter__; x() calls __call__; a + b calls __add__. This set of protocols is the data model, and it is what duck typing actually means: any type implementing __iter__ is iterable, with no shared base class required.

class Deck:
    def __init__(self, cards): self._c = cards
    def __len__(self):         return len(self._c)
    def __getitem__(self, i):  return self._c[i]

d = Deck(['A', 'K', 'Q'])
len(d)           # 3
d[0]             # 'A'
for c in d: ...  # works: __getitem__ gives sequence iteration

Implement the protocol and your object plugs into every built-in that expects it.

A type is itself an object, an instance of type. So type(3) is int, and type(int) is type. type is its own type, which bottoms out the tower.

type(3)          # <class 'int'>
type(int)        # <class 'type'>
type(type)       # <class 'type'>
int.__bases__    # (<class 'object'>,)

Every class ultimately inherits from object and is an instance of type, its metaclass. Writing class Foo: ... really calls type('Foo', bases, namespace) to build the class object. A metaclass is just a type whose instances are classes; overriding it customizes class creation, not instance behavior. You rarely need custom metaclasses, but knowing that classes are ordinary objects explains why you can store them in lists, pass them to functions, and attach attributes to them.

obj.attr is not a plain dict lookup; it runs type(obj).__getattribute__(obj, 'attr'), which follows a fixed order:

1. Walk type(obj).__mro__ for attr. If found and it is a data descriptor (defines __set__ or __delete__), use it now.
2. Otherwise check obj.__dict__, the instance dict.
3. Otherwise use a class attribute from step 1 (including non-data descriptors such as plain methods).
4. If nothing matched, call __getattr__ if the type defines one, else raise AttributeError.

So a method (a non-data descriptor) can be shadowed by an instance attribute of the same name, but a property (a data descriptor) cannot. The MRO, the method resolution order, is computed by the C3 linearization, giving one deterministic order even under multiple inheritance. Read it with Cls.__mro__.

A descriptor is an object whose type defines __get__ (and optionally __set__ or __delete__). When such an object lives on a class and you read it through an instance, Python calls its __get__ instead of returning it directly.

class Positive:
    def __set_name__(self, owner, name): self.n = '_' + name
    def __get__(self, obj, owner):
        if obj is None: return self
        return getattr(obj, self.n)
    def __set__(self, obj, value):
        if value <= 0: raise ValueError('must be > 0')
        setattr(obj, self.n, value)

class Account:
    balance = Positive()   # validates on every assignment

Defining __set__ makes it a data descriptor, which wins over the instance dict; defining only __get__ makes it non-data, which loses to the instance dict. This single mechanism powers property, classmethod, staticmethod, and ordinary methods: a function is a non-data descriptor whose __get__ binds self.

By default each instance stores attributes in a per-instance __dict__: flexible, but memory-heavy. Declaring __slots__ replaces that dict with fixed, descriptor-backed C-level storage.

class Point:
    __slots__ = ('x', 'y')
    def __init__(self, x, y): self.x, self.y = x, y

p = Point(1, 2)
p.z = 3          # AttributeError: no __dict__ to hold z

Gotchas: a subclass without its own __slots__ regains a __dict__, quietly undoing the savings; slots also interact awkwardly with multiple inheritance. Reach for __slots__ when you have vast numbers of small, fixed-shape objects, not by default.

How obj.attr resolves, in order. Data descriptors on the type win first; the instance dict comes next; non-data descriptors and class attributes come last.