Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-25 Thread Sturla Molden
On 23/01/16 22:25, Sebastian Berg wrote: Do you agree with this, or would it be a major inconvenience? I think any user of as_strided should be considered a power user. This is an inherently dangerous function, that can easily segfault the process. Anyone who uses as_strided should be

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-25 Thread Sturla Molden
On 25/01/16 18:06, Sebastian Berg wrote: That said, I guess I could agree with you in the regard that there are so many *other* awful ways to use as_strided, that maybe it really is just so bad, that improving one thing doesn't actually help anyway ;). That is roughly my position on this,

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-25 Thread Sebastian Berg
On Mo, 2016-01-25 at 16:11 +0100, Sturla Molden wrote: > On 23/01/16 22:25, Sebastian Berg wrote: > > > Do you agree with this, or would it be a major inconvenience? > > I think any user of as_strided should be considered a power user. > This > is an inherently dangerous function, that can

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-25 Thread Juan Nunez-Iglesias
I agree that it's not ideal that the return value of as_strided is writable. However, to be clear, this *would* break the API, which should not happen between minor releases when using semantic versioning. Even with a deprecation cycle, for libraries such as scikit-image that want to maintain

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-25 Thread Sebastian Berg
On Mon Jan 25 01:46:55 2016 GMT+0100, Juan Nunez-Iglesias 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 > >

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-25 Thread Nathaniel Smith
On Sun, Jan 24, 2016 at 4:46 PM, Juan Nunez-Iglesias 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

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-24 Thread Sebastian Berg
On So, 2016-01-24 at 13:00 +1100, Juan Nunez-Iglesias wrote: > I've used as_strided before to create an "endless" output array when > I didn't care about the result of an operation, just the side effect. > See eg here. So I would certainly like option to remain to get a > writeable array. In

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-24 Thread Juan Nunez-Iglesias
> 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

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-23 Thread Juan Nunez-Iglesias
I've used as_strided before to create an "endless" output array when I didn't care about the result of an operation, just the side effect. See eg here . So I would certainly like option to remain to get a

[Numpy-discussion] Make as_strided result writeonly

2016-01-23 Thread Sebastian Berg
Hi all, I have just opened a PR, to make as_strided writeonly (as default). The reasoning for this change is that an `as_strided` array often have self overlapping memory. However, writing to an array where multiple elements have the identical memory address can be confusing, and the results are

Re: [Numpy-discussion] Make as_strided result writeonly

2016-01-23 Thread Nathaniel Smith
On Sat, Jan 23, 2016 at 1:25 PM, Sebastian Berg wrote: > > Hi all, > > I have just opened a PR, to make as_strided writeonly (as default). The I think you meant readonly :-) > reasoning for this change is that an `as_strided` array often have self > overlapping