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

[Juan Nunez-Iglesias]

On Fri, Dec 28, 2018, at 10:58 AM, Ralf Gommers wrote:
> 
> Technically there's nothing we are deprecating. If anything, the one not super uncommon pattern will be that people use 0/1 instead of False/True, which works as expected now and will start raising in case we'd go with np.never_copy

Oh, no, here I meant, I'd consider `np.modes.CLIP` to be something worth advocating for if it wasn't for deprecation cycles and extremely widespread usage.

>> But now that we have good typing in Python, I think of string literals as an anti-pattern going forward.
> 
> I don't quite get that, it'll still be the most Pythonic thing to do in many API design scenarios. Adding a new class instance with unusual behavior like raising on bool() is not even a pattern, it would just be an oddity.

Oh, no, I wouldn't suggest that the class raise on boolification, I suggest that the typing module warn if something other than a bool or an np.types.CopyMode is provided. Then you can have a useful typed function signature.

>> I have a lot of sympathy for the ugliness argument, but I don't think `np.never_copy` (or e.g. `np.modes.never`) is that much worse than a string.
> 
> The point is not that `.reshape(..., copy=np.never_copy)` is uglier (it is, but indeed just a little), but that we're adding a new object to the numpy namespace that's without precedent. If we'd do that regularly the API would really blow up.

Sure, I totally agree here, which is why I suggested `np.modes.never` as an alternative. Namespaces are a honking great idea!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20181227/d2e227ea/attachment-0001.html>