On Thu, 2018-12-27 at 14:50 +0100, Eric Wieser wrote: > > I think np.never_copy is really ugly. I’d much rather simply use > > ‘never’, > > > > I actually think np.never_copy is the better choice of the two. > Arguments for it: > > It’s consistent with np.newaxis in spelling (modulo the _) > If mistyped, it can be caught easily by IDEs. > It’s typeable with mypy, unlike constant string literals which > currently aren’t > If code written against new numpy is run on old numpy, it will error > rather than doing the wrong thing
I am not sure I think that the above are too strong arguments, since it is not what is typically done for keywords (nobody suggests np.CLIP instead of "clip"). Unless you feel this is different because it is a mix of strings and bools here? > It won’t be possible to miss parts of our existing API that evaluate > a copy argument in a boolean context > It won’t be possible for downstream projects to misinterpret by not > checking for ‘never’ - an error will be raised instead. The last one is a good reason I think, since the dispatcher would pass on the string, so a downstream API user which are not picky about the input will interpret it wrong without the special argument. Unless we replace the string when dispatching, which seems strange on first sight. Overall, I am still a bit undecided right now. - Sebastian > Arguments against it: > > It’s more characters than "never" > The implementation of np.never_copy is a little verbose / ugly > Eric > > On Thu, Dec 27, 2018, 1:41 AM Ralf Gommers <ralf.gomm...@gmail.com > wrote: > > > > > On Wed, Dec 26, 2018 at 3:29 PM Sebastian Berg < > > sebast...@sipsolutions.net> wrote: > > > Hi all, > > > > > > In https://github.com/numpy/numpy/pull/11897 I am looking into > > > the > > > addition of a `copy=np.never_copy` argument to: > > > * np.array > > > * arr.reshape/np.reshape > > > * arr.astype > > > > > > Which would cause an error to be raised when numpy cannot > > > guarantee > > > that the returned array is a view of the input array. > > > The motivation is to easier avoid accidental copies of large > > > data, or > > > ensure that in-place manipulation will be meaningful. > > > > > > The copy flag API would be: > > > * `copy=True` forces a copy > > > * `copy=False` allows numpy to copy if necessary > > > * `copy=np.never_copy` will error if a copy would be necessary > > > * (almost) all other input will be deprecated. > > > > > > Unfortunately using `copy="never"` is tricky, because currently > > > `np.array(..., copy="never")` behaves exactly the same as > > > `np.array(..., copy=bool("never"))`. So that the wrong result > > > would be > > > given on old numpy versions and it would be a behaviour change. > > > > I think np.never_copy is really ugly. I'd much rather simply use > > 'never', and clearly document that if users start using this and > > they critically rely on it really being never, then they should > > ensure that their code is only used with numpy >= 1.17.0. > > > > Note also that this would not be a backwards compatibility break, > > because `copy` is now clearly documented as bool, and not bool_like > > or some such thing. So we do not need to worry about the very > > improbable case that users now are using `copy='never'`. > > > > If others think `copy='never'` isn't acceptable now, there are two > > other options: > > 1. add code first to catch `copy='never'` in 1.17.x and raise on > > it, then in a later numpy version introduce it. > > 2. just do nothing. I'd prefer that over `np.never_copy`. > > > > Cheers, > > Ralf > > > > > Some things that are a not so nice maybe: > > > * adding/using `np.never_copy` is not very nice > > > * Scalars need a copy and so will not be allowed > > > * For rare array-likes numpy may not be able to guarantee no- > > > copy, > > > although it could happen (but should not). > > > > > > > > > The history is that a long while ago I considered adding a copy > > > flag to > > > `reshape` so that it is possible to do `copy=np.never_copy` (or > > > similar) to ensure that no copy is made. In these, you may want > > > something like an assertion: > > > > > > ``` > > > new_arr = arr.reshape(new_shape) > > > assert np.may_share_memory(arr, new_arr) > > > > > > # Which is sometimes -- but should not be -- written as: > > > arr.shape = new_shape # unnecessary container modification > > > > > > # Or: > > > view = np.array(arr, order="F") > > > assert np.may_share_memory(arr, new_arr) > > > ``` > > > > > > but is more readable and will not cause an intermediate copy on > > > error. > > > > > > > > > So what do you think? Other variants would be to not expose this > > > for > > > `np.array` and probably limit `copy="never"` to the reshape > > > method. Or > > > just to not do it at all. Or to also accept "never" for > > > `reshape`, > > > although I think I would prefer to keep it in sync and wait for a > > > few > > > years to consider that. > > > > > > Best, > > > > > > Sebastian > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
