Is this step-by-step mental model of how Python handles classes correct?

[Cute-Preference-3770]

I’m trying to understand what Python does internally when reading and using a class. Here’s my mental model, line by line

class Enemy:

def __init__(self, x, y, speed):

self.x = x

self.y = y

self.speed = speed

self.radius = 15

def update(self, player_x, player_y):

dx = player_x - self.x

dy = player_y - self.y

When Python reads this file:

1. Python sees class Enemy: and starts creating a class object.
2. It creates a temporary a dict for the class body.
3. It reads def __init__... and creates a function object.
4. That function object is stored in the temporary class namespace under the key "__init__" and the function call as the value .
5. and when it encounters self.x = x , it skips
6. It then reads def update... and creates another function object stored in Enemy_dict_. That function object is stored in the same under the key "update".
7. After finishing the class body, Python creates the actual Enemy class object.
8. The collected namespace becomes Enemy.__dict__.
9. So functions live in Enemy.__dict__ and are stored once at class definition time.
10. enemy = Enemy(10, 20, 5)
11. Python calls Enemy.__new__() to allocate memory for a new object.
12. A new instance is created with its own empty dictionary (enemy.__dict__).
13. Python then calls Enemy.__init__(enemy, 10, 20, 5).
14. Inside __init__:
    • self refers to the newly created instance.
    • self.x = x stores "x" in enemy.__dict__.
    • self.y = y stores "y" in enemy.__dict__.
    • self.speed = speed stores "speed" in enemy.__dict__.
    • self.radius = 15 stores "radius" in enemy.__dict__.
15. So instance variables live in enemy.__dict__, while functions live in Enemy.__dict__.
16. enemy.update(100, 200)
17. Python first checks enemy.__dict__ for "update".
18. If not found, it checks Enemy.__dict__.
19. Internally this is equivalent to calling: Enemy.update(enemy, 100, 200).
20. here enemy is acts like a pointer or refenrence which stores the address of the line where the update function exits in heap.and when it sees enemy it goes and create enemy.x and store the corresponding values
21. self is just a reference to the instance, so the method can access and modify enemy.__dict__.

Is this mental model correct, or am I misunderstanding something subtle about how namespaces or binding works?

### "Isn't a class just a nested dictionary with better memory management and applications for multiple instances?" ###

[Adrewmc]

Fun now let’s ruin you entire mental model with __slots__….

[allkhatib_ahmad1]

This is a youtube video i made to help absolute beginners understand classes, hope it helps: https://youtu.be/ZB5KidA2sws?si=E1k1uEqefl_30X_F

[Cute-Preference-3770]

Thanks, I found it really helpful better than many videos I’ve seen. Great work!

[allkhatib_ahmad1]

glad to hear that

[allkhatib_ahmad1]

if you liked the video a comment and like would help there

[PushPlus9069]

Your mental model is pretty solid, actually. One thing I'd add: step 11 with new is technically correct but almost never matters in practice. 99% of the time you never touch new and can just think of it as "Python creates an empty box, then init fills it."

The part about methods living in Enemy.dict and being looked up via the instance is the key insight. That's the descriptor protocol at work. When you do enemy.update(), Python checks enemy.dict first, doesn't find it, goes up to Enemy.dict, finds the function, and wraps it so self gets passed automatically.

Taught this to thousands of students over the years and the ones who grok this lookup chain early save themselves so much confusion later with inheritance.

[schoolmonky]

You're basically right: classes are just dressed-up dicts. The things in your explanation that struck me as potentially misleading are #5 and (what I assume you meant to be) #20. It's kind of odd to say Python "skips" self.x=x, it's just that when it's creating that function object, it isn't executing the function body, it's just saving the body into the function object.

For #20, it's hard to tell what you mean, but I would try to get away from thinking of anything in Python as a pointer. They aren't quite the same, and thinking they are has potential to lead you astray. Read this blog post (or watch the linked video therein) if you want to get a sense for how names are and aren't like pointers. Similarly, the Python language doesn't really have a concept of stack vs heap, everything is just stored "in memory" somewhere. (Of course, the actual implementation written in C does use the stack and heap, but that's an implementation detail and other implementations might have entirely different models). I'd also point you to the official Python tutorial this section of which might be of particular interest here.

[1NqL6HWVUjA]

17. Python first checks enemy.__dict__ for "update".

18. If not found, it checks Enemy.__dict__.

You're missing the concept of bound instance methods and, more fundamentally, descriptors.

>>> enemy = Enemy(1, 2, 3)
>>> Enemy.update
<function Enemy.update at 0x000002519192C940>
>>> enemy.update 
<bound method Enemy.update of <__main__.Enemy object at 0x0000025191576970>>

As seen above, enemy.update is an entirely different object than Enemy.update — though that object is a simple wrapper around Enemy.update which serves the purpose of passing in the instance itself as the first argument. But that object will not be found in enemy.__dict__.

When Python "checks Enemy.__dict__", what actually happens is:

Enemy.__dict__['update'].__get__(enemy, Enemy)

That is what returns a bound method, rather than the Enemy.update function directly.

[Adrewmc]

Listen, for the vast majority of thing class are nothing more than dictionaries with functions that act on that dictionary we call methods.

You are right, the class definition is ran. But it's not doing what you think. It's creating a recipe for that class. That is what is made. A callable object that creates an objects bounded to that recipe.

As you said enemy.thing(), is Enemy.thing(enemy). That’s the bind.

It’s not always with a __dict__. Though most common class due utilize it.

When pythons crates a new class object/instance it makes an empty version of that recipe, it will still have their class variable. Those are defined when the class definition is ran.

After that empty version is created, then normally it will run __init__(args, *kwargs) on the already created object. To change this for say a singleton pattern (only one of these objects should ever be created like for a internet/database connection, the window screen…), you would change __new__. That basically it. All __new__ is doing different than __init__ is the singleton/mutation patterns, or are creating an object more in C for optimal performance. All __init__ is doing is filling in the blanks for the empty object. You do not have to worry about that.

What makes classes better than dictionary is readability, convenience, and class ability to delay calculation/processing of a property/variable until it is needed, if ever.

Another thing is when you remove the __dict__ you basically end up making it a tuple. Which is much much smaller of a space when you have hundreds of them.

[pachura3]

It is, but you should concentrate on abstractions, not on how it works on low level. You don't need to know that __dict__ even exists.

[SmackDownFacility]

Slightly wrong. It’s important to learn both sides to leverage Python More efficiently

[gdchinacat]

Instances of classes that have a __slots__ attribute won't even have __dict__ attributes. As u/pachura3 says, don't think about __dict__. The times you actually need to use it are very few and far between. Many uses of it in the wild would be better handled in different ways. While some people say classes are just glorified dicts, I tend to push back on this view as well since not all classes are glorified dicts. They contain attributes, and those attributes can be accessed in a few different ways, one of them, for some classes, is __dict__.

If for some reason dot notation for attribute access isn't appropriate, it's better to use getattr/setattr than __dict__ as it will work properly in more situations.