Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Ralf Gommers]

On Mon, Jul 5, 2021 at 3:53 AM Stefan van der Walt 
wrote:

> On Sun, Jul 4, 2021, at 13:00, Ralf Gommers wrote:
>
> I don't think so. We basically arrived at the solution, and there's a PR
> that is mostly done too. This really isn't that complicated that we should
> require a NEP.
>
>
> Personally, I don't like np.CopyMode in the main namespace. If we can
> agree to stash it somewhere else, and tentatively aim to move to strings at
> point X in time for consistency with the rest of the API, I have no issue
> with going ahead.
>

I share your dislike, but I don't really see a better place where it
doesn't make it even harder to spell, but I did just think of an
alternative that may actually be quite reasonable: keep it private. The
reason why Gagandeep started working on this is so we can have the
never-copy behavior in the `numpy.array_api` namespace. For the `asarray`
function there, the `copy` keyword is still boolean, with description:

Whether or not to make a copy of the input. If True, always copies.
If False, never copies for input which supports DLPack or the buffer
protocol,
and raises ValueError in case that would be necessary.
If None , reuses existing memory buffer if possible, copies otherwise.
Default: None.

In the end I think that's better than strings, and way better than enums -
we just can't have that in the main namespace, because we can't change what
`False` does.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Mon, Jul 5, 2021, at 00:42, Ralf Gommers wrote:
> I share your dislike, but I don't really see a better place where it doesn't 
> make it even harder to spell, but I did just think of an alternative that may 
> actually be quite reasonable: keep it private.

That would be fine.  We haven't had this feature requested for many years, so 
as long as it is available in some shape or form it should satisfy the advanced 
users who need it.  It also doesn't force us into a decision we cannot reverse 
(adding to the top-level API).

> The reason why Gagandeep started working on this is so we can have the 
> never-copy behavior in the `numpy.array_api` namespace. For the `asarray` 
> function there, the `copy` keyword is still boolean, with description:
> 
> Whether or not to make a copy of the input. If ` True`, always copies. 
> If ` False`, never copies for input which supports DLPack or the buffer 
> protocol, 
> and raises ` ValueError`` `in case that would be necessary. 
> If ` None ` , reuses existing memory buffer if possible, copies 
> otherwise. 
> Default: ` None`. 
> 
> In the end I think that's better than strings, and way better than enums - we 
> just can't have that in the main namespace, because we can't change what 
> `False` does.

I agree  that 
this is a good API (although not everybody else does). 


W.r.t. NumPy's API: it could be okay to change the behavior of copy=False to 
make it more strict (no copies ever), because then at least errors will be 
raised and we can provide a message with instructions on how to fix it.

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion