On Thu, Dec 27, 2018 at 3:27 PM Juan Nunez-Iglesias <jni.soma@gmail.com> wrote:
On Fri, Dec 28, 2018, at 3:40 AM, Sebastian Berg wrote:
> 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?

:+1: to Eric's list. I don't think it's different because of the mix, I think it's different because deprecating things is painful.

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

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.


But, for me, the biggest reason is the silent different behaviour in old vs new NumPy. As a package maintainer this is just a nightmare.

That is the main downside indeed in this particular case.


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.

np.newaxis is not relevant here - it's a simple alias for None, is just there for code readability, and is much more widely applicable than np.never_copy would be.

Cheers,
Ralf