On Thu, Jan 10, 2019, 01:55 Eric Wieser <wieser.eric+nu...@gmail.com wrote:
> 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…) > What about a namespace as someone mentioned earlier. Perhaps `np.flags.NO_COPY` 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 > Would all three conditions be supported this way or only `NEVER`? >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
