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 <hangen...@gmail.com> wrote: > On Sun, Sep 30, 2012 at 10:35 PM, Travis Oliphant <tra...@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 <hangen...@gmail.com> wrote: >> >>> On Sun, Sep 30, 2012 at 9:59 PM, Travis Oliphant <tra...@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@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@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
