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@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@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@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion