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
On Mon, Jan 7, 2019 at 11:30 AM Eric Wieser
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