“is” operation returns false even though two objects have same id [duplicate]
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
This question already has an answer here:
id() vs `is` operator. Is it safe to compare `id`s? Does the same `id` mean the same object?
1 answer
Two python objects have the same id but "is" operation returns false as shown below:
a = np.arange(12).reshape(2, -1)
c = a.reshape(12, 1)
print("id(c.data)", id(c.data))
print("id(a.data)", id(a.data))
print(c.data is a.data)
print(id(c.data) == id(a.data))
Here is the actual output:
id(c.data) 241233112
id(a.data) 241233112
False
True
My question is... why "c.data is a.data" returns false even though they point to the same ID, thus pointing to the same object? I thought that they point to the same object if they have same ID or am I wrong? Thank you!
python numpy
marked as duplicate by ivan_pozdeev, smci, Community♦ yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
|
show 13 more comments
This question already has an answer here:
id() vs `is` operator. Is it safe to compare `id`s? Does the same `id` mean the same object?
1 answer
Two python objects have the same id but "is" operation returns false as shown below:
a = np.arange(12).reshape(2, -1)
c = a.reshape(12, 1)
print("id(c.data)", id(c.data))
print("id(a.data)", id(a.data))
print(c.data is a.data)
print(id(c.data) == id(a.data))
Here is the actual output:
id(c.data) 241233112
id(a.data) 241233112
False
True
My question is... why "c.data is a.data" returns false even though they point to the same ID, thus pointing to the same object? I thought that they point to the same object if they have same ID or am I wrong? Thank you!
python numpy
marked as duplicate by ivan_pozdeev, smci, Community♦ yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
1
@C.Nivs They don't even necessarily have different memory addresses (something which Python doesn't expose). Whatever memory was used for the first may have been reused for the second.
– chepner
2 days ago
3
@C.Nivs Don't think of it in terms of memory addresses. How memory is managed is completely implementation dependent. All you know for sure is that two objects that overlap in time will not have the same id.
– chepner
2 days ago
1
@Aran-Fey, that's okay a good question(though asked before) can sometimes be resurrected for a fruitful discussion
– amanb
2 days ago
4
@C.Nivs no, ids do not belong to variables. They belong to objects. Many variables can reference the same object.
– juanpa.arrivillaga
2 days ago
2
@juanpa.arrivillaga fair enough. Thanks for the explanation
– C.Nivs
2 days ago
|
show 13 more comments
This question already has an answer here:
id() vs `is` operator. Is it safe to compare `id`s? Does the same `id` mean the same object?
1 answer
Two python objects have the same id but "is" operation returns false as shown below:
a = np.arange(12).reshape(2, -1)
c = a.reshape(12, 1)
print("id(c.data)", id(c.data))
print("id(a.data)", id(a.data))
print(c.data is a.data)
print(id(c.data) == id(a.data))
Here is the actual output:
id(c.data) 241233112
id(a.data) 241233112
False
True
My question is... why "c.data is a.data" returns false even though they point to the same ID, thus pointing to the same object? I thought that they point to the same object if they have same ID or am I wrong? Thank you!
python numpy
This question already has an answer here:
id() vs `is` operator. Is it safe to compare `id`s? Does the same `id` mean the same object?
1 answer
Two python objects have the same id but "is" operation returns false as shown below:
a = np.arange(12).reshape(2, -1)
c = a.reshape(12, 1)
print("id(c.data)", id(c.data))
print("id(a.data)", id(a.data))
print(c.data is a.data)
print(id(c.data) == id(a.data))
Here is the actual output:
id(c.data) 241233112
id(a.data) 241233112
False
True
My question is... why "c.data is a.data" returns false even though they point to the same ID, thus pointing to the same object? I thought that they point to the same object if they have same ID or am I wrong? Thank you!
This question already has an answer here:
id() vs `is` operator. Is it safe to compare `id`s? Does the same `id` mean the same object?
1 answer
python numpy
python numpy
edited yesterday
user2357112
158k13177270
158k13177270
asked 2 days ago
drminixdrminix
615
615
marked as duplicate by ivan_pozdeev, smci, Community♦ yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by ivan_pozdeev, smci, Community♦ yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
1
@C.Nivs They don't even necessarily have different memory addresses (something which Python doesn't expose). Whatever memory was used for the first may have been reused for the second.
– chepner
2 days ago
3
@C.Nivs Don't think of it in terms of memory addresses. How memory is managed is completely implementation dependent. All you know for sure is that two objects that overlap in time will not have the same id.
– chepner
2 days ago
1
@Aran-Fey, that's okay a good question(though asked before) can sometimes be resurrected for a fruitful discussion
– amanb
2 days ago
4
@C.Nivs no, ids do not belong to variables. They belong to objects. Many variables can reference the same object.
– juanpa.arrivillaga
2 days ago
2
@juanpa.arrivillaga fair enough. Thanks for the explanation
– C.Nivs
2 days ago
|
show 13 more comments
1
@C.Nivs They don't even necessarily have different memory addresses (something which Python doesn't expose). Whatever memory was used for the first may have been reused for the second.
– chepner
2 days ago
3
@C.Nivs Don't think of it in terms of memory addresses. How memory is managed is completely implementation dependent. All you know for sure is that two objects that overlap in time will not have the same id.
– chepner
2 days ago
1
@Aran-Fey, that's okay a good question(though asked before) can sometimes be resurrected for a fruitful discussion
– amanb
2 days ago
4
@C.Nivs no, ids do not belong to variables. They belong to objects. Many variables can reference the same object.
– juanpa.arrivillaga
2 days ago
2
@juanpa.arrivillaga fair enough. Thanks for the explanation
– C.Nivs
2 days ago
1
1
@C.Nivs They don't even necessarily have different memory addresses (something which Python doesn't expose). Whatever memory was used for the first may have been reused for the second.
– chepner
2 days ago
@C.Nivs They don't even necessarily have different memory addresses (something which Python doesn't expose). Whatever memory was used for the first may have been reused for the second.
– chepner
2 days ago
3
3
@C.Nivs Don't think of it in terms of memory addresses. How memory is managed is completely implementation dependent. All you know for sure is that two objects that overlap in time will not have the same id.
– chepner
2 days ago
@C.Nivs Don't think of it in terms of memory addresses. How memory is managed is completely implementation dependent. All you know for sure is that two objects that overlap in time will not have the same id.
– chepner
2 days ago
1
1
@Aran-Fey, that's okay a good question(though asked before) can sometimes be resurrected for a fruitful discussion
– amanb
2 days ago
@Aran-Fey, that's okay a good question(though asked before) can sometimes be resurrected for a fruitful discussion
– amanb
2 days ago
4
4
@C.Nivs no, ids do not belong to variables. They belong to objects. Many variables can reference the same object.
– juanpa.arrivillaga
2 days ago
@C.Nivs no, ids do not belong to variables. They belong to objects. Many variables can reference the same object.
– juanpa.arrivillaga
2 days ago
2
2
@juanpa.arrivillaga fair enough. Thanks for the explanation
– C.Nivs
2 days ago
@juanpa.arrivillaga fair enough. Thanks for the explanation
– C.Nivs
2 days ago
|
show 13 more comments
2 Answers
2
active
oldest
votes
a.data and c.data both produce a transient object, with no reference to it. As such, both are immediately garbage-collected. The same id can be used for both.
In your first if statement, the objects have to co-exist while is checks if they are identical, which they are not.
In the second if statement, each object is released as soon as id returns its id.
If you save references to both objects, keeping them alive, you can see they are not the same object.
r0 = a.data
r1 = c.data
assert r0 is not r1
5
what is confusing is the fact thatdatalooks like an attribute, but is probably a property
– Jean-François Fabre♦
2 days ago
In my tests, the id's are different in the first run, but change to become the same on subsequent runs.
– amanb
2 days ago
@Jean-FrançoisFabre so would that mean that the object itself is only returned when a getter is called, and the property is not actually stored in the class? I'm not quite familiar with the differences between a property vs attribute
– C.Nivs
2 days ago
6
a property is a method disguised as an attribute. So it can return a discardable integer, object, whatever.
– Jean-François Fabre♦
2 days ago
Thank you all! Coming from C/C++, I was just looking for a way to check if two different pointers point to the same object. So I should use "is operator" to compare if check if two pointers point to the same object. id() can return the same string since it can be re-used for transient objects. Thanks
– drminix
yesterday
|
show 1 more comment
In [62]: a = np.arange(12).reshape(2,-1)
...: c = a.reshape(12,1)
.data returns a memoryview object. id just gives the id of that object; it's not the value of the object, or any indication of where a databuffer is located.
In [63]: a.data
Out[63]: <memory at 0x7f672d1101f8>
In [64]: c.data
Out[64]: <memory at 0x7f672d1103a8>
In [65]: type(a.data)
Out[65]: memoryview
https://docs.python.org/3/library/stdtypes.html#memoryview
If you want to verify that a and c share a data buffer, I find the __array_interface__ to be a better tool.
In [66]: a.__array_interface__['data']
Out[66]: (50988640, False)
In [67]: c.__array_interface__['data']
Out[67]: (50988640, False)
It even shows the offset produced by slicing - here 24 bytes, 3*8
In [68]: c[3:].__array_interface__['data']
Out[68]: (50988664, False)
I haven't seen much use of a.data. It can be used as the buffer object when creating a new array with ndarray:
In [70]: d = np.ndarray((2,6), dtype=a.dtype, buffer=a.data)
In [71]: d
Out[71]:
array([[ 0, 1, 2, 3, 4, 5],
[ 6, 7, 8, 9, 10, 11]])
In [72]: d.__array_interface__['data']
Out[72]: (50988640, False)
But normally we create new arrays with shared memory with slicing or np.array (copy=False).
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
a.data and c.data both produce a transient object, with no reference to it. As such, both are immediately garbage-collected. The same id can be used for both.
In your first if statement, the objects have to co-exist while is checks if they are identical, which they are not.
In the second if statement, each object is released as soon as id returns its id.
If you save references to both objects, keeping them alive, you can see they are not the same object.
r0 = a.data
r1 = c.data
assert r0 is not r1
5
what is confusing is the fact thatdatalooks like an attribute, but is probably a property
– Jean-François Fabre♦
2 days ago
In my tests, the id's are different in the first run, but change to become the same on subsequent runs.
– amanb
2 days ago
@Jean-FrançoisFabre so would that mean that the object itself is only returned when a getter is called, and the property is not actually stored in the class? I'm not quite familiar with the differences between a property vs attribute
– C.Nivs
2 days ago
6
a property is a method disguised as an attribute. So it can return a discardable integer, object, whatever.
– Jean-François Fabre♦
2 days ago
Thank you all! Coming from C/C++, I was just looking for a way to check if two different pointers point to the same object. So I should use "is operator" to compare if check if two pointers point to the same object. id() can return the same string since it can be re-used for transient objects. Thanks
– drminix
yesterday
|
show 1 more comment
a.data and c.data both produce a transient object, with no reference to it. As such, both are immediately garbage-collected. The same id can be used for both.
In your first if statement, the objects have to co-exist while is checks if they are identical, which they are not.
In the second if statement, each object is released as soon as id returns its id.
If you save references to both objects, keeping them alive, you can see they are not the same object.
r0 = a.data
r1 = c.data
assert r0 is not r1
5
what is confusing is the fact thatdatalooks like an attribute, but is probably a property
– Jean-François Fabre♦
2 days ago
In my tests, the id's are different in the first run, but change to become the same on subsequent runs.
– amanb
2 days ago
@Jean-FrançoisFabre so would that mean that the object itself is only returned when a getter is called, and the property is not actually stored in the class? I'm not quite familiar with the differences between a property vs attribute
– C.Nivs
2 days ago
6
a property is a method disguised as an attribute. So it can return a discardable integer, object, whatever.
– Jean-François Fabre♦
2 days ago
Thank you all! Coming from C/C++, I was just looking for a way to check if two different pointers point to the same object. So I should use "is operator" to compare if check if two pointers point to the same object. id() can return the same string since it can be re-used for transient objects. Thanks
– drminix
yesterday
|
show 1 more comment
a.data and c.data both produce a transient object, with no reference to it. As such, both are immediately garbage-collected. The same id can be used for both.
In your first if statement, the objects have to co-exist while is checks if they are identical, which they are not.
In the second if statement, each object is released as soon as id returns its id.
If you save references to both objects, keeping them alive, you can see they are not the same object.
r0 = a.data
r1 = c.data
assert r0 is not r1
a.data and c.data both produce a transient object, with no reference to it. As such, both are immediately garbage-collected. The same id can be used for both.
In your first if statement, the objects have to co-exist while is checks if they are identical, which they are not.
In the second if statement, each object is released as soon as id returns its id.
If you save references to both objects, keeping them alive, you can see they are not the same object.
r0 = a.data
r1 = c.data
assert r0 is not r1
edited 2 days ago
answered 2 days ago
chepnerchepner
262k36251345
262k36251345
5
what is confusing is the fact thatdatalooks like an attribute, but is probably a property
– Jean-François Fabre♦
2 days ago
In my tests, the id's are different in the first run, but change to become the same on subsequent runs.
– amanb
2 days ago
@Jean-FrançoisFabre so would that mean that the object itself is only returned when a getter is called, and the property is not actually stored in the class? I'm not quite familiar with the differences between a property vs attribute
– C.Nivs
2 days ago
6
a property is a method disguised as an attribute. So it can return a discardable integer, object, whatever.
– Jean-François Fabre♦
2 days ago
Thank you all! Coming from C/C++, I was just looking for a way to check if two different pointers point to the same object. So I should use "is operator" to compare if check if two pointers point to the same object. id() can return the same string since it can be re-used for transient objects. Thanks
– drminix
yesterday
|
show 1 more comment
5
what is confusing is the fact thatdatalooks like an attribute, but is probably a property
– Jean-François Fabre♦
2 days ago
In my tests, the id's are different in the first run, but change to become the same on subsequent runs.
– amanb
2 days ago
@Jean-FrançoisFabre so would that mean that the object itself is only returned when a getter is called, and the property is not actually stored in the class? I'm not quite familiar with the differences between a property vs attribute
– C.Nivs
2 days ago
6
a property is a method disguised as an attribute. So it can return a discardable integer, object, whatever.
– Jean-François Fabre♦
2 days ago
Thank you all! Coming from C/C++, I was just looking for a way to check if two different pointers point to the same object. So I should use "is operator" to compare if check if two pointers point to the same object. id() can return the same string since it can be re-used for transient objects. Thanks
– drminix
yesterday
5
5
what is confusing is the fact that
data looks like an attribute, but is probably a property– Jean-François Fabre♦
2 days ago
what is confusing is the fact that
data looks like an attribute, but is probably a property– Jean-François Fabre♦
2 days ago
In my tests, the id's are different in the first run, but change to become the same on subsequent runs.
– amanb
2 days ago
In my tests, the id's are different in the first run, but change to become the same on subsequent runs.
– amanb
2 days ago
@Jean-FrançoisFabre so would that mean that the object itself is only returned when a getter is called, and the property is not actually stored in the class? I'm not quite familiar with the differences between a property vs attribute
– C.Nivs
2 days ago
@Jean-FrançoisFabre so would that mean that the object itself is only returned when a getter is called, and the property is not actually stored in the class? I'm not quite familiar with the differences between a property vs attribute
– C.Nivs
2 days ago
6
6
a property is a method disguised as an attribute. So it can return a discardable integer, object, whatever.
– Jean-François Fabre♦
2 days ago
a property is a method disguised as an attribute. So it can return a discardable integer, object, whatever.
– Jean-François Fabre♦
2 days ago
Thank you all! Coming from C/C++, I was just looking for a way to check if two different pointers point to the same object. So I should use "is operator" to compare if check if two pointers point to the same object. id() can return the same string since it can be re-used for transient objects. Thanks
– drminix
yesterday
Thank you all! Coming from C/C++, I was just looking for a way to check if two different pointers point to the same object. So I should use "is operator" to compare if check if two pointers point to the same object. id() can return the same string since it can be re-used for transient objects. Thanks
– drminix
yesterday
|
show 1 more comment
In [62]: a = np.arange(12).reshape(2,-1)
...: c = a.reshape(12,1)
.data returns a memoryview object. id just gives the id of that object; it's not the value of the object, or any indication of where a databuffer is located.
In [63]: a.data
Out[63]: <memory at 0x7f672d1101f8>
In [64]: c.data
Out[64]: <memory at 0x7f672d1103a8>
In [65]: type(a.data)
Out[65]: memoryview
https://docs.python.org/3/library/stdtypes.html#memoryview
If you want to verify that a and c share a data buffer, I find the __array_interface__ to be a better tool.
In [66]: a.__array_interface__['data']
Out[66]: (50988640, False)
In [67]: c.__array_interface__['data']
Out[67]: (50988640, False)
It even shows the offset produced by slicing - here 24 bytes, 3*8
In [68]: c[3:].__array_interface__['data']
Out[68]: (50988664, False)
I haven't seen much use of a.data. It can be used as the buffer object when creating a new array with ndarray:
In [70]: d = np.ndarray((2,6), dtype=a.dtype, buffer=a.data)
In [71]: d
Out[71]:
array([[ 0, 1, 2, 3, 4, 5],
[ 6, 7, 8, 9, 10, 11]])
In [72]: d.__array_interface__['data']
Out[72]: (50988640, False)
But normally we create new arrays with shared memory with slicing or np.array (copy=False).
add a comment |
In [62]: a = np.arange(12).reshape(2,-1)
...: c = a.reshape(12,1)
.data returns a memoryview object. id just gives the id of that object; it's not the value of the object, or any indication of where a databuffer is located.
In [63]: a.data
Out[63]: <memory at 0x7f672d1101f8>
In [64]: c.data
Out[64]: <memory at 0x7f672d1103a8>
In [65]: type(a.data)
Out[65]: memoryview
https://docs.python.org/3/library/stdtypes.html#memoryview
If you want to verify that a and c share a data buffer, I find the __array_interface__ to be a better tool.
In [66]: a.__array_interface__['data']
Out[66]: (50988640, False)
In [67]: c.__array_interface__['data']
Out[67]: (50988640, False)
It even shows the offset produced by slicing - here 24 bytes, 3*8
In [68]: c[3:].__array_interface__['data']
Out[68]: (50988664, False)
I haven't seen much use of a.data. It can be used as the buffer object when creating a new array with ndarray:
In [70]: d = np.ndarray((2,6), dtype=a.dtype, buffer=a.data)
In [71]: d
Out[71]:
array([[ 0, 1, 2, 3, 4, 5],
[ 6, 7, 8, 9, 10, 11]])
In [72]: d.__array_interface__['data']
Out[72]: (50988640, False)
But normally we create new arrays with shared memory with slicing or np.array (copy=False).
add a comment |
In [62]: a = np.arange(12).reshape(2,-1)
...: c = a.reshape(12,1)
.data returns a memoryview object. id just gives the id of that object; it's not the value of the object, or any indication of where a databuffer is located.
In [63]: a.data
Out[63]: <memory at 0x7f672d1101f8>
In [64]: c.data
Out[64]: <memory at 0x7f672d1103a8>
In [65]: type(a.data)
Out[65]: memoryview
https://docs.python.org/3/library/stdtypes.html#memoryview
If you want to verify that a and c share a data buffer, I find the __array_interface__ to be a better tool.
In [66]: a.__array_interface__['data']
Out[66]: (50988640, False)
In [67]: c.__array_interface__['data']
Out[67]: (50988640, False)
It even shows the offset produced by slicing - here 24 bytes, 3*8
In [68]: c[3:].__array_interface__['data']
Out[68]: (50988664, False)
I haven't seen much use of a.data. It can be used as the buffer object when creating a new array with ndarray:
In [70]: d = np.ndarray((2,6), dtype=a.dtype, buffer=a.data)
In [71]: d
Out[71]:
array([[ 0, 1, 2, 3, 4, 5],
[ 6, 7, 8, 9, 10, 11]])
In [72]: d.__array_interface__['data']
Out[72]: (50988640, False)
But normally we create new arrays with shared memory with slicing or np.array (copy=False).
In [62]: a = np.arange(12).reshape(2,-1)
...: c = a.reshape(12,1)
.data returns a memoryview object. id just gives the id of that object; it's not the value of the object, or any indication of where a databuffer is located.
In [63]: a.data
Out[63]: <memory at 0x7f672d1101f8>
In [64]: c.data
Out[64]: <memory at 0x7f672d1103a8>
In [65]: type(a.data)
Out[65]: memoryview
https://docs.python.org/3/library/stdtypes.html#memoryview
If you want to verify that a and c share a data buffer, I find the __array_interface__ to be a better tool.
In [66]: a.__array_interface__['data']
Out[66]: (50988640, False)
In [67]: c.__array_interface__['data']
Out[67]: (50988640, False)
It even shows the offset produced by slicing - here 24 bytes, 3*8
In [68]: c[3:].__array_interface__['data']
Out[68]: (50988664, False)
I haven't seen much use of a.data. It can be used as the buffer object when creating a new array with ndarray:
In [70]: d = np.ndarray((2,6), dtype=a.dtype, buffer=a.data)
In [71]: d
Out[71]:
array([[ 0, 1, 2, 3, 4, 5],
[ 6, 7, 8, 9, 10, 11]])
In [72]: d.__array_interface__['data']
Out[72]: (50988640, False)
But normally we create new arrays with shared memory with slicing or np.array (copy=False).
edited 2 days ago
answered 2 days ago
hpauljhpaulj
118k787160
118k787160
add a comment |
add a comment |
1
@C.Nivs They don't even necessarily have different memory addresses (something which Python doesn't expose). Whatever memory was used for the first may have been reused for the second.
– chepner
2 days ago
3
@C.Nivs Don't think of it in terms of memory addresses. How memory is managed is completely implementation dependent. All you know for sure is that two objects that overlap in time will not have the same id.
– chepner
2 days ago
1
@Aran-Fey, that's okay a good question(though asked before) can sometimes be resurrected for a fruitful discussion
– amanb
2 days ago
4
@C.Nivs no, ids do not belong to variables. They belong to objects. Many variables can reference the same object.
– juanpa.arrivillaga
2 days ago
2
@juanpa.arrivillaga fair enough. Thanks for the explanation
– C.Nivs
2 days ago