I understand the principal theory behind Everything is an Object but I really don't understand how it is implemented under the hood.
Functions
So: foo(4) is the same as foo.__call__(4). But what is stopping me from doing foo.__call__.__call__(4)?
foo is a function and foo.__call__... are all method wrappers around the function but when I call a function, which of these is even invoked?
All those properties
My function of foo has a lot of properties, and each of those objects store a lot of properties, so how does it not take up infinite memory?
sys.getsizeof('a') produces 22, which seems quite large for one character, but quite small as it references 71 properties.
I guess what I am asking is if I wanted to implement a naïve version of python (I don't but it seems the best way to ask) how would I implement this?
Edit 1
I had a bit of a look at builtins and realised that they are referencing the same properties (id('a'.upper) == id('b'.upper)). Which makes me ask how it knows what object it is accessing?
Edit 2 As pts points out 'a'.upper is not 'b'.upper, so that clears that up.
I've looked at the source for IronPython as I thought it would help me understand but it has confused me even more.
I think what you're getting confused with is that although all of Python's variables might be objects and all the properties of those variables might be objects, there is a limit. I mean, for a normal class the structure usually goes:
myclass -> classobj -> type
which you can see if you try this in the console:
>> class A:
.. pass
..
>> print type(A)
<type 'classobj'>
>> print type(type(A))
<type 'type'>
but if you try and go deeper than type, you just get type. type is the base object for all objects in Python.
>> print type(type(type(A)))
<type 'type'>
>> print type(type(type(type(type(A)))))
<type 'type'>
Not only do you get the same base class/object type, but you get the same instance of that type for the class instance of A, so although you can do an infinite recursion of the function type (ie. type(type(type(type(... ))))), you won't be going anywhere (ie. not exploring a bottomless pit of infinite memory.)
>> id(type(type(type(A)))
505578544
>> id(type(type(type(type(A))))
505578544
The same principle applies for all the objects in Python and all the properties of the objects in Python since they too are objects, but they are all finite.
Answering one of your earlier questions,
foo.__call__ is the same instance of 'method-wrapper' as foo.__call__.__call__
So nothing is stopping you from doing a very long line with foo.__call__.__call__.__call__...
Python plays a trick on you in that foo.__call__ gives a instance to 'method-wrapper', and inside that 'method-wrapper' class there is a function/variable also called __call__ that points to the same instance of that class.
Your assumption that if everything is an object, foo(4) must automatically translate to foo.__call__(4) is wrong.
Python can first check if the object foo is a function, and if so call it, and do other things (like look for a __call__ attribute) otherwise.
You can think of an "object" as a pointer to it's dictionary of data members and a pointer to its type's dictionary of data members (usually including methods of the type). These are usually a finite space and the type's dictionary is shared by all objects of the type. (This is an over-simplification, but probably good enough to understand why it isn't infinite memory).
The id anomaly is caused by early reference counting: the Python memory manager frees 'a'.upper too early, and then 'b'.upper gets allocated to the same memory address.
Early free:
>>> id('a'.upper), id('b'.upper)
(3073677900L, 3073677900L)
No early free:
>>> x, y = 'a'.upper, 'b'.upper
>>> id(x), id(y)
(3073678252L, 3073677900L)
>>> x, y
(<built-in method upper of str object at 0xb7317b20>, <built-in method upper of str object at 0xb7317b40>)
Comparison by reference:
>>> 'a'.upper is 'b'.upper
False
