On Sun, Jan 24, 2016 at 4:46 PM, Juan Nunez-Iglesias <jni.s...@gmail.com> wrote: >> Yeah, that is a real use case. I am not planning to remove the option, >> but it would be as a `readonly` keyword argument, which means you would >> need to make the code depend on the numpy version if you require a >> writable array [1]. >> >> [1] as_strided does not currently support arr.flags.writable = True for > its result array. > > Can you explain this in more detail? I'm writing to the result without > problem.
I think what Sebastian's saying is: - right now it returns an array with the writeable flag set to True - it would make more sense semantically (in the general "try to nudge people towards not shooting themselves in the foot" sense) if by default it returned an array with the writeable flag set to False - of course it should still be possible to get an array with writeable=True by explicitly requesting it (e.g. with as_strided(..., writeable=True)). - The transition period then would be that it continues to default to writeable=True, but if you don't specify writeable=True, and then you write to the array, it works but it issues a DeprecationWarning telling you that you ought to update your code to explicitly request writeable=True at some point over the next ~year. - Often, if you have a readonly ndarray object, you can actually switch it to being writeable by executing `a.flags.writeable = True`. This is a bit hacky, and there are various safety conditions that have to hold, but often it works. Except it turns out that if as_strided is modified to return a readonly array, then some details of those safety checks mean that this trick *doesn't* work -- if it was created readonly, then it will stay that way. This doesn't really matter, though -- it just means that you have to use something like a writeable=True kwarg to ensure that it gets created writeable in the first place, instead of creating it readonly and then fixing it up after the fact. But it does rule this out as a possible alternative API. Oh well, it'd be pretty klunky anyway. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
