On Sep 27, 2007, at 2:47 PM, Fernando Perez wrote:
> The problematic issue is that some extensions (numpy first and
> foremost, but this buffer API is going into the core of the language
> for 2.6/3.0) allow multiple, distinct *python objects* to share the
> same (or parts of the same) chunk of raw memory. The refcount
> mechanism only tracks python objects, not raw memory.
Yes, but that's all we care about. If an implementation of an object
points to the memory of another object, it assume that the other
chunk of memory may change.
> Hopefully this
> helps:
>
> In [12]: a = N.arange(10)
>
> In [13]: sys.getrefcount(a)
> Out[13]: 2
>
> Here the refcount is 2, as expected: the original array and the name
> 'a' pointing to it.
>
> Now, a naked, unassigned slice of the original array has a refcount
> of 1:
>
> In [14]: sys.getrefcount(a[::2])
> Out[14]: 1
>
> And yet, modifying it in-place has an effect on the original object
> (which we have called 'a'):
>
> In [15]: a[::2].fill(999)
>
> In [16]: a
> Out[16]: array([999, 1, 999, 3, 999, 5, 999, 7, 999, 9])
>
>
> The slice 'a[::2]' has a refcount of 1, so it appears 'safe' from a
> purely refcounting argument. But it actually shares memory with the
> original N.arange(10) object, so it can overwrite it.
This is by design, and a slice object wants to mutate the underlying
object. And slice objects know that their mutations may have side
effects. The object being sliced ('a' in this example) knows it is
unsafe because b holds a reference to it. (If b held a pointer into
the memory of a, but no reference, that memory would be in risk of
getting recycled) .
> Note that I'm only pointing this out as a word of caution that there
> are cases where refcounting arguments can be a bit delicate. The
> basic idea of reusing in-place objects as an optimization is a very
> good one for cases where you know that your underlying objects simply
> don't expose any interface for antics like the above.
I agree with your caution, but don't see how the examples above mess
anything up. If an object B wants to pretend to be immutable, it
merely has to check that nothing points to it before mutating itself
(and, in mutating itself, don't mutate objects that have other
pointers to them).
- Robert
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
