Understanding Python Decorators and FastAPI Internals

I've been using @decorators But Today I finally understood what happens in memory when Python sees that @ symbol. Here's the full picture — with actual RAM addresses 👇 When Python runs your script, it creates function objects in memory immediately: decorator() → stored at address 0x7668...2e0 just_a_func() → stored at address 0x7668...380 The moment you call decorator(just_a_func), something new happens: A brand new object do_something() is born at 0x7668...420 Inside do_something(), the func argument holds a reference to just_a_func's address — 0x7668...380 The original just_a_func() is never modified. It stays at the same address. So @decorator is just clean syntax for: decorated = decorator(just_a_func) That's it. No magic. Just references. Now the FastAPI part — and this is where it gets interesting. @app.get("/ping") is NOT a decorator itself. It's a function that RETURNS a decorator. Under the hood: — app.get("/ping") calls APIRouter.api_route() — api_route() returns a decorator(func) function — that decorator calls add_api_route(path, func) — your route function is now registered in the app's memory state You can actually do this manually without @ syntax: decorator = app.get("/ping") decorated = decorator(new_route) Same result. Just less elegant. The deeper I go into FastAPI internals, the more I appreciate how cleanly it's built. Everything is explicit, traceable, and follows Python's own function object model. This is what "learning in public" looks like — going beyond the docs and into the source code. What concept in your stack did you finally understand by reading the source code? #Python #FastAPI #Decorators #LearningInPublic #BackendDevelopment #100DaysOfCode #SoftwareEngineering #PythonTips #WebDevelopment For More In Dept Visit : https://lnkd.in/d7-rqhzQ

  • graphical user interface, website

To view or add a comment, sign in

Explore content categories