By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,818 Members | 1,262 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,818 IT Pros & Developers. It's quick & easy.

Memory addressing

P: n/a
Hi,

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.

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.

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?

Regards,

Apr 27 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On Fri, 2007-04-27 at 12:41 -0700, Simon Berube wrote:
Hi,

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?

-Carsten
Apr 27 '07 #2

P: n/a
On Apr 27, 3:52 pm, Carsten Haese <cars...@uniqsys.comwrote:
On Fri, 2007-04-27 at 12:41 -0700, Simon Berube wrote:
Hi,
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?

-Carsten
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 Addresshappen. 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 Addressstrings to recreate
a an object.

I hope this is clearer.
Apr 27 '07 #3

P: n/a
Simon Berube wrote:
When you call certain objects __repr__() strings in python you
often get the : <Object at Memory Addresshappen. 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.
It cannot. The string returned by repr is supposed to be unique. In
C Python, it just happens to be the object's memory address that's
used to make this string unique.
In short, how do I used <Object at Memory Addressstrings to
recreate a an object.
Not at all :) Objects that can't be recreated using their __repr__
information just provide an unique identifier string if you call
repr on them, no more and no less.

Regards,
Björn

--
BOFH excuse #202:

kernel panic: write-only-memory (/dev/wom0) capacity exceeded.

Apr 27 '07 #4

P: n/a
In <11*********************@n35g2000prd.googlegroups. com>, Simon Berube
wrote:
In short, how do I used <Object at Memory Addressstrings to recreate
a an object.
You already got the answer: you can't. Either you still have a reference
to that object, or the memory address is not guaranteed to point to the
object anymore even if you could get an object from a "raw" memory address.

Ciao,
Marc 'BlackJack' Rintsch
Apr 27 '07 #5

P: n/a
On Fri, 2007-04-27 at 12:56 -0700, Simon Berube wrote:
When you call certain objects __repr__() strings in python you often
get the : <Object at Memory Addresshappen. 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.
It's not a requirement of repr() that the resulting string be suitable
for recreating the object. For many built-in object types, calling
eval() on their repr() will result in a copy of the object, but in
general eval(repr(obj))==obj will not be true.
In short, how do I used <Object at Memory Addressstrings to recreate
a an object.
You don't. What you should do instead depends on what you actually need
to do, which you haven't said yet. Do you want to pass an object to
another function, do you want to make a copy of an object, or do you
want to serialize/unserialize an object to send it through time and/or
space?

-Carsten
Apr 27 '07 #6

P: n/a
On Apr 27, 4:00 pm, Carsten Haese <cars...@uniqsys.comwrote:
On Fri, 2007-04-27 at 12:56 -0700, Simon Berube wrote:
When you call certain objects __repr__() strings in python you often
get the : <Object at Memory Addresshappen. 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.

It's not a requirement of repr() that the resulting string be suitable
for recreating the object. For many built-in object types, calling
eval() on their repr() will result in a copy of the object, but in
general eval(repr(obj))==obj will not be true.
In short, how do I used <Object at Memory Addressstrings to recreate
a an object.

You don't. What you should do instead depends on what you actually need
to do, which you haven't said yet. Do you want to pass an object to
another function, do you want to make a copy of an object, or do you
want to serialize/unserialize an object to send it through time and/or
space?

-Carsten
That's what we need: a CopyMemory() routine.

Apr 27 '07 #7

P: n/a
On 27 abr, 20:07, castiro...@gmail.com wrote:
That's what we need: a CopyMemory() routine.
See the copy and pickle modules.

--
Gabriel Genellina

Apr 27 '07 #8

P: n/a
Well what I was looking for is more along the lines of if it was
possible to assign an object at a fixed memory address like C. But
most importantly I was expecting it to be a bad habbit in python and
was simply wondering what was the accepted manner of doing so.

I did know everything was passed by reference in Python but I was
simply curious about the ability to just use

*f1 = memory_address

In order to create an object. The only use I saw for this was in the
case of a string returning the memory location albeit from the replies
I got that this would not really be desirable and necessary. I was
really just trying to avoid developping bad habbits or depending on
something that shouldnt be used commonly in the language.

I think my question has been answered well so I would like to thank
everyone for their input. Albeit a memory copy function would be fun
to use but ultimately not very fit for such a high level language I
suppose.

Again, thank you everyone this forum is very helpful,

Regards,
On Apr 27, 7:51 pm, Gabriel Genellina <gagsl-...@yahoo.com.arwrote:
On 27 abr, 20:07, castiro...@gmail.com wrote:
That's what we need: a CopyMemory() routine.

See the copy and pickle modules.

--
Gabriel Genellina

Apr 28 '07 #9

P: n/a
Simon Berube wrote:
On Apr 27, 3:52 pm, Carsten Haese <cars...@uniqsys.comwrote:
>>On Fri, 2007-04-27 at 12:41 -0700, Simon Berube wrote:
>>>Hi,
>> 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?

-Carsten


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 Addresshappen. 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 Addressstrings 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
object.

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.

James
Apr 28 '07 #10

P: n/a
On Fri, 27 Apr 2007 16:07:57 -0700, castironpi wrote:
That's what we need: a CopyMemory() routine.
What we _really_ need are Poke() and Peek() routines.
--
Steven.

Apr 28 '07 #11

P: n/a
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
On Fri, 27 Apr 2007 16:07:57 -0700, castironpi wrote:
That's what we need: a CopyMemory() routine.

What we _really_ need are Poke() and Peek() routines.
You can easily write them with ctypes (it's part of the standard library
now, too) -- at least on systems where you can easily access the C
runtime library as a dynamic library, such as Windows, Linux, and
MacOSX, but I imagine it wouldn't be that much harder on others (I
haven't really looked in depth at the lowest-level functionality offered
by ctype, as the higher-level stuff is plenty sufficient to get a lot of
core dumps:-).
Alex
Apr 28 '07 #12

P: n/a
"Steven D'Aprano" <st..@REMOVE.THIS.cy...e.com.auwrote:

On Fri, 27 Apr 2007 16:07:57 -0700, castironpi wrote:
That's what we need: a CopyMemory() routine.

What we _really_ need are Poke() and Peek() routines.
Yeah right! - we also need macros, then an assembler johnny
like me can hack his own syntax using only macros, peek
and poke...

And still claim he's writing programmes in python.

- Hendrik

Apr 29 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.