Memory addressing

James Stroud jstroud at
Sat Apr 28 03:09:44 CEST 2007

Simon Berube wrote:
> On Apr 27, 3:52 pm, Carsten Haese <cars... at> wrote:
>>On Fri, 2007-04-27 at 12:41 -0700, Simon Berube wrote:
>>>   I have a rather simple question for which I couldn't find an
>>>answer. I noticed how a significant number of objects in Python return
>>>a __repr__() string along the lines of :
>>>< Object at 0xXXXXXX>
>>>   I find this notation quite convenient to avoid out of control
>>>strings when using large arrays but I was wondering how you can use
>>>the memory address for assigning a new object.
>>You can't.
>>>In c, one could simple have a pointer to that memory address and
>>>voila, you have a new object you can analyze however it seems like
>>>python is allergic to direct memory manipulation.
>>For good reason. Python is not C.
>>>Hence, I was wondering what is the correct way to go about obtaining
>>>objects returned in such a fashion? What am I going wrong or what am I
>>>not getting?
>>What is the actual problem you're trying to solve?
> First of all, thanks for your reply. I am not trying to solve a
> problem in particular, I know that my way of thinking of very wrong in
> a python sense and I am simply trying to find the equivalent accepted
> practice.
> When you call certain objects __repr__() strings in python you often
> get the : <Object at Memory Address> happen. I am simply trying to
> understand how that information can be used to recreate a certain
> object that failed as per the given purpose of the __repr__()
> functions.
> In short, how do I used <Object at Memory Address> strings to recreate
> a an object.
> I hope this is clearer.

I typed this before I realized it was essentially what everyone else has 
said. I'm posting it to make myself feel better than if I were to simply 
delete it.

If you can call __repr__() on an object, then you already have a 
reference to it. If you have a reference to an object, then, in 
principle, you can create a copy of that object from the reference, 
rendering __repr__() unnecessary.

It makes no senese to pass around a __repr__() of an object and attempt 
to create it from the __repr__(). This is because, in actuality, you 
would be passing around a reference to the returned value from 
__repr__() and so you might as well be passing a reference to the actual 

Obviously, you can not simply store the __repr__() output and hope to 
re-create the object later, say between invocations of the interpreter. 
You would either need the contents of the object stored or you would 
need to know those contents via a reference (in the same invocation). In 
short, you propose to do accounting that you should otherwise allow the 
interpreter to do for you.


More information about the Python-list mailing list