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 On Wed, 9 Jan 2019 at 22:25 Ralf Gommers <ralf.gomm...@gmail.com> wrote: > On Mon, Jan 7, 2019 at 11:30 AM Eric Wieser <wieser.eric+nu...@gmail.com> > wrote: > >> >> @Ralf >> >> 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. >> >> Is there any particular reason we chose to use None? If I were designing >> it again, I’d consider a singleton object with a better __repr__ >> > It stems from Numeric: > https://mail.python.org/pipermail/python-list/2009-September/552203.html. > Note that the Python builtin slice also uses None, but that's probably due > to Numeric using it first. > > Agree that a singleton with a nice repr could be a better choice than > None. The more important part of my comment was "widely applicable" though. > 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. > > Cheers, > Ralf > > > >> _______________________________________________ > 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
