[Numpy-discussion] Behavior of .base

[Nathaniel Smith]

On Mon, Oct 1, 2012 at 3:40 PM, Thouis (Ray) Jones <thouis at gmail.com> wrote:
> On Mon, Oct 1, 2012 at 8:20 AM, Nathaniel Smith <njs at pobox.com> wrote:
>> [...]
>> How can we discourage people from doing this in the future? Can we
>> make .base write-only from the Python level (with suitable deprecation
>> period)? Rename it to ._base (likewise) so that it's still possible to
>> peek under the covers but we remind people that it's really an
>> implementation detail with poorly defined semantics that might change?
>
> Could we use the simpler .base behavior (fully collapsing the .base
> chain), but be more aggressive about propagating information like
> address/filename/offset for np.arrays that are created by slicing,
> asarray(), etc.?

There are definitely other solutions to the memmap pickling problem
that don't rely on the semantics of .base at all, yeah. I don't
particularly like the one you suggest, because it requires that many
pieces of code in many places all be careful to preserve this
information, whereas keeping a global table of the process's active
memory maps requires only a single piece of new code in the memmap
module (and will be more reliable to boot). But strictly speaking the
details here are irrelevant to the discussion about .base itself.
There are two questions about .base:
1) Is it okay to break people's code when we release 1.7, given that
they have relied on this behaviour that they probably ought not to
have?
2) Can we untangle things enough that making changes to .base *won't*
break people's code, so that we don't end up having to ask question
(1) again in the future?

I'm totally happy with deciding that we need to band-aid the 1.7
release b/c working code is working code and breaking it isn't okay,
so long as we also address question (2).

-n