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
