[Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
rainwoodman at gmail.com
Mon Jan 7 14:21:51 EST 2019
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.
On Fri, Dec 28, 2018 at 5:45 AM Sebastian Berg <sebastian at sipsolutions.net>
> 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
> - Sebastian
> > -n
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion