If you have not already read through it, there is a ton of useful information about Python’s data model in the user manual; it is my go-to resource when I want to do weird stuff with metaclasses and the like.

Furthermore, you might find it interesting to peruse the C code that is generated by Cython, because it gives you a concrete view of the kinds of steps that Python has to go through from a C perspective to work within its data model. (Cython is a bit faster than Python because it does not have to interpret bytecode, but unless you use special directives it still has to e.g. do general attribute lookups whenever you interact with a Python value, even if the value is an integer, and maintain reference counts.)

Finally, you might also get a lot out of skimming through the CPython bytecode instructions, as this has a lot of interesting details about how the bytecode interpreter works in practice.

Some of those details are portable, particularly the behavior of code objects. Function declarations (def statements) bind code objects to names within a namespace; binding within a class namespace will create methods by calling the declared metaclass, which defaults to the type() builtin type object.

Some other details are not portable. CPython stores code objects on the C heap and allocates generic closures; it supports either a dict from strings to locals, or user-declared slots naming a tuple of locals. PyPy automatically computes slots in all cases and supports the dict as a special case. Threads generally share a single heap per interpreter, so the creation of threads doesn’t matter for declaring or instantiating objects; note that the community makes this work by pushing the convention that .__init__() methods should not do computation and instead should merely initialize the locals, akin to similar conventions in C++. That said, Jython threads are Java threads, not OS threads like in CPython or PyPy, so normal assumptions about threading may not hold.

You will have to let go of some of your practices around memory management. Python is memory-safe and garbage-collected by default; while sometimes you’ll want to remove names or map keys with del, it usually isn’t necessary. Similarly, while there are maybe a half-dozen ways to customize class creation and memory layout, it’s almost never actually necessary to use more than one of them at a time. Instead, stick to writing Pythonic code, and let runtimes like PyPy worry about performance. PyPy goes fast by simplifying what happens under the hood; if it exposed guaranteed internal structure then it would be slower.

There’s the Cpython Internals book, as well as Brett Cannon’s Syntatic Sugar which I think might help with some of your questions (though admittedly, I’m just interested in data sciencey stuff)

Do you mean function definitions? They are executable statements after all. Yes the Python environment is just a bunch of nested dictionaries. Whether there is bytecode is up to the implementation. If you want to understand how CPython works, the source code is not terribly mysterious if you know C. You will want to read the API document first.

For the language itself, the reference manuals are reasonably good.

I guess when you want to know how it works under the hood, this article may give you a good overview. “under the hood” is my go to keyword when I want to know more about the internals.

https://www.codewithc.com/how-python-works-under-the-hood-pythons-internal-mechanics

search for w3schools

deleted by creator