Slicing is a lot more important than some keyword. And design-wise, filling the numpy namespace with singletons for keyword to other things in that same namespace just makes no sense to me.

At least from the perspective of discoverability, you could argue that string constants form a namespace of their won, and so growing the “string” namespace is not inherently better than growing any other. The main flaw in that comparison is that picking np.never_copy to be a singleton forever prevents us reusing that name to become a function.

Perhaps the solution is to use np.NEVER_COPY instead - that’s never going to clash with a function name we want to add in future, and using upper attributes as arguments in that way is pretty typical for python (subprocess.PIPE, socket.SOCK_STREAM, etc…)

You could fairly argue that this approach is outdated in the face of enum.Enum - in which case we could go for the more heavy-handed np.CopyMode.NEVER, which still has a unique enough case for name clashes with functions never to be an issue.

Eric