[Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

[Eric Wieser]

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.gommers at gmail.com> wrote:

> On Mon, Jan 7, 2019 at 11:30 AM Eric Wieser <wieser.eric+numpy at 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190109/f8c2227f/attachment-0001.html>