Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is it possible to get the Physical memory address of a variable in python?

3,485 views
Skip to first unread message

Sourabh Kalal

unread,
Jan 23, 2017, 12:59:42 PM1/23/17
to
how we can access the value from using id..
like x=10
id(x)
3235346364

how i can read value 10 using id 3235346364

Chris Angelico

unread,
Jan 23, 2017, 1:49:20 PM1/23/17
to
No, you can't. That isn't a memory address - it's just a unique
identifier. Python doesn't have memory addresses.

ChrisA

Terry Reedy

unread,
Jan 23, 2017, 2:00:56 PM1/23/17
to
On 1/23/2017 12:49 PM, Sourabh Kalal wrote:
> how we can access the value from using id..
> like x=10
> id(x)
> 3235346364
>
> how i can read value 10 using id 3235346364

*In Python*, you cannot. Ids are mainly for internal use of
implementations. Implementors also use them to test their implementation.

*CPython* comes with a module (ctypes) that can be used to muck around
with interpreter internals, but it is definitely not for beginners. I
don't know about other implementations.

--
Terry Jan Reedy

Skip Montanaro

unread,
Jan 23, 2017, 2:06:13 PM1/23/17
to
On Mon, Jan 23, 2017 at 12:49 PM, Chris Angelico <ros...@gmail.com> wrote:
>
> On Tue, Jan 24, 2017 at 4:49 AM, Sourabh Kalal <kalal...@gmail.com> wrote:
> > how we can access the value from using id..
> > like x=10
> > id(x)
> > 3235346364
> >
> > how i can read value 10 using id 3235346364
>
> No, you can't. That isn't a memory address - it's just a unique
> identifier. Python doesn't have memory addresses.

Well, it might be, but that would be very implementation-dependent.
Any attempt to treat an id as a memory address and interpret the
object at that address as the beginning of a PyObject of any kind will
be fragile in the extreme. Even if you have two different
implementations at hand which both use memory addresses as convenient
ids, there's no guarantee that the address represents that start of a
CPython PyObject.

>>> hex(3235346364)
'0xc0d777bc'

There. *Now* you have an address. Hack to your heart's content. <wink>

Skip

Peter Otten

unread,
Jan 23, 2017, 2:35:06 PM1/23/17
to
Sourabh Kalal wrote:

> how we can access the value from using id..
> like x=10
> id(x)
> 3235346364
>
> how i can read value 10 using id 3235346364

Use ctypes:

$ python3
Python 3.4.3 (default, Nov 17 2016, 01:08:31)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.c_ubyte.from_address(id(10) + 24).value = 11
>>> 10 == 11
True

:)

Chris Angelico

unread,
Jan 23, 2017, 3:17:46 PM1/23/17
to
On Tue, Jan 24, 2017 at 6:05 AM, Skip Montanaro
<skip.mo...@gmail.com> wrote:
> On Mon, Jan 23, 2017 at 12:49 PM, Chris Angelico <ros...@gmail.com> wrote:
>>
>> On Tue, Jan 24, 2017 at 4:49 AM, Sourabh Kalal <kalal...@gmail.com> wrote:
>> > how we can access the value from using id..
>> > like x=10
>> > id(x)
>> > 3235346364
>> >
>> > how i can read value 10 using id 3235346364
>>
>> No, you can't. That isn't a memory address - it's just a unique
>> identifier. Python doesn't have memory addresses.
>
> Well, it might be, but that would be very implementation-dependent.
> Any attempt to treat an id as a memory address and interpret the
> object at that address as the beginning of a PyObject of any kind will
> be fragile in the extreme. Even if you have two different
> implementations at hand which both use memory addresses as convenient
> ids, there's no guarantee that the address represents that start of a
> CPython PyObject.
>
>>>> hex(3235346364)
> '0xc0d777bc'
>
> There. *Now* you have an address. Hack to your heart's content. <wink>

No, you now have a hexadecimal representation of an integer. Memory
addresses are integers; Python object identifiers are also integers.
The fact that they may happen to correspond *in CPython* is basically
a coincidence.

In a language like C, where pointers and memory addresses are real
things, you can work with an integer and dereference it to get the
data at that address. In BASIC, where I first learned programming, you
have specific instructions to mess with memory (I have fond memories
of messing around with segment zero to change the status of Caps Lock
etc, and of peeking and poking in video memory, and stuff). But in
Python, that exists only in ctypes, and that only because ctypes is
basically C.

rosuav@sikorsky:~$ python3
Python 3.7.0a0 (default:cebc9c7ad195, Jan 24 2017, 06:55:19)
[GCC 6.2.0 20161027] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> objs = [object() for _ in range(10)]
>>> [id(x) for x in objs]
[140652901773504, 140652901773520, 140652901773536, 140652901773552,
140652901773568, 140652901773584, 140652901773600, 140652901773616,
140652901773632, 140652901773648]

These could well be memory addresses, but...

>>> objs = [object() for _ in range(10)]
>>> [id(x) for x in objs]
[2, 3, 4, 5, 6, 7, 8, 9, 10, 11]

... these almost certainly aren't. They are, however, unique integer
values (the 'objs' list guarantees that all objects are simultaneously
alive, ergo the IDs must be unique). Other Python implementations are
free to do what they like. Quite a few do seem to use something like a
memory address (uPy, PyPy, PyPyJS), but not all:

Brython 3.3.0 on Netscape 5.0 (X11; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
>>> objs = [object() for _ in range(10)]
>>> [id(x) for x in objs]
[54, 55, 56, 57, 58, 59, 60, 61, 62, 63]

There's basically no way to go from an ID to the object. If you know
what data type it is (eg an integer, as in the OP's example), you can
reach in and grab the contents, but there's no way to write this
function:

def deref(id):
... # ????
assert deref(id(x)) is x

The best you could do, in terms of parlour tricks, is to test it only
on small integers, where ctypes can get you the value of the integer,
and thanks to small-int-caching, it will actually be the same object.
But it won't work for larger integers.

It's not a pointer.

ChrisA

Michael Torrie

unread,
Jan 23, 2017, 3:24:58 PM1/23/17
to
On 01/23/2017 10:49 AM, Sourabh Kalal wrote:
> how we can access the value from using id..
> like x=10
> id(x)
> 3235346364
>
> how i can read value 10 using id 3235346364

Many objects in python such as numbers like 10 or strings are immutable;
they can never be altered once called into existance. When you assign
to a variable, you are binding the variable name to an object. So if
you later took your x variable and re-assigned it to value 11, the id of
x would change to reflect this new object 11.

If you could find the memory address in your example where 10 is stored,
and then modified it, you could mess up a lot of things because the
interpreter is free to optimize and to use the same 10 object every
places where 10 is assigned to a variable.

Skip Montanaro

unread,
Jan 23, 2017, 3:26:45 PM1/23/17
to
On Mon, Jan 23, 2017 at 2:17 PM, Chris Angelico <ros...@gmail.com> wrote:
>> There. *Now* you have an address. Hack to your heart's content. <wink>
>
> No, you now have a hexadecimal representation of an integer.

You missed my attempt at levity, I think.

S

Chris Angelico

unread,
Jan 23, 2017, 3:32:47 PM1/23/17
to
Ahh, I guess I did.

Sadly, it is all too true that there is no statement so ridiculous
that it's unquestionably a joke. An ill-informed person could easily
come out with exactly the same comment. :(

ChrisA

bream...@gmail.com

unread,
Jan 23, 2017, 4:21:25 PM1/23/17
to
What are you trying to achieve here? If you'd explain that rather than how you're trying to achieve it you're likely to get better answers.

Kindest regards.

Mark Lawrence.

dieter

unread,
Jan 24, 2017, 5:00:02 AM1/24/17
to
Sourabh Kalal <kalal...@gmail.com> writes:

> how we can access the value from using id..
> like x=10
> id(x)
> 3235346364
>
> how i can read value 10 using id 3235346364

You should not do this (read the value instead by looking at "x") --
unless you are debugging at "C" level. For "C" level debugging,
there is a set of "gdb" macros allowing you to display Python
objects giving their "C" level address.

0 new messages