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

[Feng Yu]

Hi,

Was it ever brought up the possibility of a new array class (ndrefonly,
ndview) that is strictly no copy?

All operations on ndrefonly will return ndrefonly and if the operation
cannot be completed without making a copy, it shall throw an error.

On the implementation there are two choices if we use subclasses:

- ndrefonly can be a subclass of ndarray. The pattern would be subclass
limiting functionality of super, but ndrefonly is a ndarray.
- ndarray as a subclass of ndarray. Subclass supplements functionality of
super. : ndarray will not throw an error when a copy is necessary. However
ndarray is not a ndarray.

If we want to be wild they do not even need to be subclasses of each other,
or maybe they shall both be subclasses of something more fundamental.

- Yu


On Fri, Dec 28, 2018 at 5:45 AM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Thu, 2018-12-27 at 17:45 -0800, Nathaniel Smith wrote:
> > On Thu, Dec 27, 2018 at 3:27 PM Juan Nunez-Iglesias <
> > jni.soma at gmail.com> wrote:
> > > On Fri, Dec 28, 2018, at 3:40 AM, Sebastian Berg wrote:
> > >
> > > > It’s consistent with np.newaxis in spelling (modulo the _)
> > > > If mistyped, it can be caught easily by IDEs.
> > > > It’s typeable with mypy, unlike constant string literals which
> > > > currently aren’t
> > > > If code written against new numpy is run on old numpy, it will
> > > > error
> > > > rather than doing the wrong thing
> > >
> > > I am not sure I think that the above are too strong arguments,
> > > since it
> > > is not what is typically done for keywords (nobody suggests np.CLIP
> > > instead of "clip"). Unless you feel this is different because it is
> > > a
> > > mix of strings and bools here?
> > >
> > >
> > > :+1: to Eric's list. I don't think it's different because of the
> > > mix, I think it's different because deprecating things is painful.
> > > But now that we have good typing in Python, I think of string
> > > literals as an anti-pattern going forward.
> >
> > I've certainly seen people argue that it's better to use proper
> > enum's
> > in this kind of case instead of strings. The 'enum' package is even
> > included in the stdlib on all our supported versions now:
> > https://docs.python.org/3/library/enum.html
> >
>
> I am sympathetic with that, but it is something we (or scipy, etc.)
> currently simply do not use, so I am not sure that I think it has much
> validity at this time. That is least unless we agree to aim to use this
> more generally in the future.
>
> > I guess another possibility to throw out there would be a second
> > kwarg, require_view=False/True.
> >
>
> My first gut feeling was that it is clumsy at least for `reshape`, but
> one will always only use one of the two arguments at a time.
> The more I look at it, the better the suggestion seems. Plus it reduces
> the possible `copy=False` not meaning "never" confusion.
>
> I think with a bit more pondering, that will become my favorite
> solution.
>
> - Sebastian
>
>
> > -n
> >
> _______________________________________________
> 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/20190107/2eba3170/attachment.html>