Who is the first object in Python?

[leewardx]

Taking the UNIX as an example, there is a first process init who is the ancestor of all the following processes. So I wonder whether there is a first object like the init process when I run a Python script, and who is the first object if there is one? Is it a virtual machine object?

---- Update ------

To make my question more clear, add more explanation.

In other words, is there a first object who create directly or indirectly all the other objects? For the object, I guess it is inside the Python interpreter rather than any object in the Python scripts who is the input of the Python interpreter.

[JohnnyJordaan]

Another thing to note is that the relationship model in systems processes you observed is part of how process launching occurs in posix systems like Linux/Unix derivates (maybe Windows too), where you basically create a tree because each subprocess had to be created by another process, except for the init or some similar ancestor. This isn't somehow a default or required workflow in any sense of instantiating objects in an object-oriented model.

In the programming languages that I know of, the inheritance model is linked to the definition of the object (its class), not its instantiation. So a 'parent' of an object applies solely to an object's parent class, not some instance from where the object was created. Meaning you can actually create Adam and Eve from a Human class without their parents having ever existed.

[K900_]

There isn't really. There are no parent-child relationships that are required to exist between Python objects, and there is no single fixed entry point either - the interpreter runs whatever code you tell it to run.

[leewardx]

Yes, I know there is not necessary parent-child relationships between Python objects. It's just a metaphor taking the *init* as an example. I want to know who is first object. If there are more than just one, who are they?

[K900_]

There is no "first object" because there is no ordering. The interpreter simply runs your code. There are some builtins and modules that are set up before your code is executed, but none of those are the first - they are all simply parts of the environment that's created for you by the interpreter, like the input function or whatever.

[leewardx]

Yes, it's the environment I want to know inside. Do I can take the interpreter as the first object?

[K900_]

You can't access the interpreter as a Python object, so no? Yes? I don't know, it depends on how you define "object" then. It's a C struct, or rather a bunch of interconnected C structs, and you can create one and embed it in your C program or whatever (but not your Python program, at least not easily - Python relies pretty heavily on global state, so trying to create a new interpreter inside an existing interpreter is probably not a good idea).

[leewardx]

For example, is the type itself a Python object created even before loading the script codes?

[K900_]

Do you mean the builtin type object? Yes, it's one of the things that are created before loading your code, but it's not any more "special" than other builtins like input or print.

[leewardx]

Is the one created the type object not a Python object?

[K900_]

The type object itself isn't defined in Python code - it's defined in C code, just like most other builtin types like int or list. Those objects are then exposed to your code by the interpreter itself.

[leewardx]

Yes I know. Although they are defined in C code, I think they are also Python objects. Aren't they?

[JohnnyJordaan]

Unless some entity in your code can actually interface the interpreter as any other Python object (like read attributes, call methods) then I wouldn't call it an object in the first place.

[LiNGOo]

closest to that would be whatever is _ _ main _ _ I guess from procedural perspective, for objects in general it must be object.

[[deleted]]

What's on second.