[Numpy-discussion] Behavior of .base

[Han Genuit]

On Sun, Sep 30, 2012 at 10:55 PM, Travis Oliphant <travis at continuum.io> wrote:
> I think you are misunderstanding the proposal.   The proposal is to traverse the views as far as you can but stop just short of having base point to an object of a different type.
>
> This fixes the infinite chain of views problem but also fixes the problem sklearn was having with base pointing to an unexpected mmap object.
>
> --
> Travis Oliphant
> (on a mobile)
> 512-826-7480
>
>
> On Sep 30, 2012, at 3:50 PM, Han Genuit <hangenuit at gmail.com> wrote:
>
>> On Sun, Sep 30, 2012 at 10:35 PM, Travis Oliphant <travis at continuum.io> wrote:
>>> We are not talking about changing it "back".  The change in 1.6 caused problems that need to be addressed.
>>>
>>> Can you clarify your concerns?  The proposal is not a major change to the behavior on master, but it does fix a real issue.
>>>
>>> --
>>> Travis Oliphant
>>> (on a mobile)
>>> 512-826-7480
>>>
>>>
>>> On Sep 30, 2012, at 3:30 PM, Han Genuit <hangenuit at gmail.com> wrote:
>>>
>>>> On Sun, Sep 30, 2012 at 9:59 PM, Travis Oliphant <travis at continuum.io> wrote:
>>>>> Hey all,
>>>>>
>>>>> In a github-discussion with Gael and Nathaniel, we came up with a proposal for .base that we should put before this list.    Traditionally, .base has always pointed to None for arrays that owned their own memory and to the "most immediate" array object parent for arrays that did not own their own memory.   There was a long-standing issue related to running out of stack space that this behavior created.
>>>>>
>>>>> Recently this behavior was altered so that .base always points to "the original" object holding the memory (something exposing the buffer interface).   This created some problems for users who relied on the fact that most of the time .base pointed to an instance of an array object.
>>>>>
>>>>> The proposal here is to change the behavior of .base for arrays that don't own their own memory so that the .base attribute of an array points to "the most original object" that is still an instance of the type of the array.      This would go into the 1.7.0 release so as to correct the issues reported.
>>>>>
>>>>> What are reactions to this proposal?
>>>>>
>>>>> -Travis
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> NumPy-Discussion mailing list
>>>>> NumPy-Discussion at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>
>>>> I think the current behaviour of the .base attribute is much more
>>>> stable and predictable than past behaviour. For views for instance,
>>>> this makes sure you don't hold references of 'intermediate' views, but
>>>> always point to the original *base* object. Also, I think a lot of
>>>> internal logic depends on this behaviour, so I am not in favour of
>>>> changing this back (yet) again.
>>>>
>>>> Also, considering that this behaviour already exists in past versions
>>>> of NumPy, namely 1.6, and is very fundamental to how arrays work, I
>>>> find it strange that it is now up for change in 1.7 at the last
>>>> minute.
>>>> _______________________________________________
>>>> NumPy-Discussion mailing list
>>>> NumPy-Discussion at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>> Well, the current behaviour makes sure you can have an endless chain
>> of views derived from each other without keeping a copy of each view
>> alive. If I understand correctly, you propose to change this behaviour
>> to where it would keep a copy of each view alive.. My concern is that
>> the problems that occurred from the 1.6 change are now seen as
>> paramount above a correct implementation. There are problems with
>> backward compatibility, but most of these are due to lack of
>> documentation and testing. And now there will be a lot of people
>> depending on the new behaviour, which is also something to take into
>> account.
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion


Ah, sorry, I get it. You mean to make sure that base is an object of
type ndarray. No problems there. :-)