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