On Sun, Sep 30, 2012 at 10:55 PM, Travis Oliphant <tra...@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 <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
Ah, sorry, I get it. You mean to make sure that base is an object of type ndarray. No problems there. :-) _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
