[Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

[Eric Wieser]

I don’t think a NEVERCOPY entry in arr.flags would make much sense.
Is this really a sensible limitation to put on how data gets used? Isn’t it
up to the algorithm to decide whether to copy its data, not the original
owner of the data?

It also leads to some tricky questions of precedence - would np.array(arr,
copy=True) respect the flag or the argument? How about np.array(arr)? Is arr
+ 0 considered a copy?
By keeping it as a value passed in via a copy= kwarg, we don’t need to
answer any of those questions.

Eric

On Thu, 10 Jan 2019 at 20:28 Ralf Gommers ralf.gommers at gmail.com
<http://mailto:ralf.gommers@gmail.com> wrote:

On Thu, Jan 10, 2019 at 11:21 AM Feng Yu <rainwoodman at gmail.com> wrote:
>
>> Hi Todd,
>>
>> I agree a flag is more suitable than classes.
>>
>> I would add another bonus of a flag than a function argument is to avoid
>> massive contamination of function signatures for a global variation of
>> behavior that affects many functions.
>>
>
> I like this suggestion. Copy behavior fits very nicely with existing flags
> (e.g. UPDATEIFCOPY, WRITEABLE) and avoids both namespace pollution and
> complication docstrings.
>
> Ralf
>
>
>> Yu
>>
>> On Wed, Jan 9, 2019 at 11:34 PM Todd <toddrjen at gmail.com> wrote:
>>
>>> On Mon, Jan 7, 2019, 14:22 Feng Yu <rainwoodman at gmail.com wrote:
>>>
>>>> Hi,
>>>>
>>>> Was it ever brought up the possibility of a new array class (ndrefonly,
>>>> ndview) that is strictly no copy?
>>>>
>>>> All operations on ndrefonly will return ndrefonly and if the operation
>>>> cannot be completed without making a copy, it shall throw an error.
>>>>
>>>> On the implementation there are two choices if we use subclasses:
>>>>
>>>> - ndrefonly can be a subclass of ndarray. The pattern would be subclass
>>>> limiting functionality of super, but ndrefonly is a ndarray.
>>>> - ndarray as a subclass of ndarray. Subclass supplements functionality
>>>> of super. : ndarray will not throw an error when a copy is necessary.
>>>> However ndarray is not a ndarray.
>>>>
>>>> If we want to be wild they do not even need to be subclasses of each
>>>> other, or maybe they shall both be subclasses of something more
>>>> fundamental.
>>>>
>>>> - Yu
>>>>
>>>
>>> I would prefer a flag for this.  Someone can make an array read-only by
>>> setting `arr.flags.writable=False`.  So along those lines, we could have a
>>> `arr.flags.copyable` flag that if set to `False` would result in an error
>>> of any operation tried to copy the data.
>>>
>>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190112/1f86fc2c/attachment.html>