-- Travis Oliphant (on a mobile) 512-826-7480
On Sep 30, 2012, at 4:00 PM, Han Genuit <hangen...@gmail.com> wrote: > 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. :-) Yes. Exactly. I realize I didn't explain it very well. For a subtype it would ensure base is a subtype. Thanks for feedback. Travis > _______________________________________________ > 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
