Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
Hi Todd, I agree a flag is more suitable than classes. I would add another bonus of a flag than a function argument is to avoid massive contamination of function signatures for a global variation of behavior that affects many functions. Yu On Wed, Jan 9, 2019 at 11:34 PM Todd wrote: > On Mon, Jan 7, 2019, 14:22 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 >> > > I would prefer a flag for this. Someone can make an array read-only by > setting `arr.flags.writable=False`. So along those lines, we could have a > `arr.flags.copyable` flag that if set to `False` would result in an error > of any operation tried to copy the data. > >> ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
constants are easier to support for autocompletion than strings. My current env (emacs) will (usually) autocomplete the former, but not the latter. On Thu, Jan 10, 2019 at 2:21 PM Feng Yu wrote: > Hi Todd, > > I agree a flag is more suitable than classes. > > I would add another bonus of a flag than a function argument is to avoid > massive contamination of function signatures for a global variation of > behavior that affects many functions. > > Yu > > On Wed, Jan 9, 2019 at 11:34 PM Todd wrote: > >> On Mon, Jan 7, 2019, 14:22 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 >>> >> >> I would prefer a flag for this. Someone can make an array read-only by >> setting `arr.flags.writable=False`. So along those lines, we could have a >> `arr.flags.copyable` flag that if set to `False` would result in an error >> of any operation tried to copy the data. >> >>> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
> On 10 Jan 2019, at 6:35 pm, Todd wrote: > > Could this approach be used to deprecate `ravel` and let us just use > `flatten`? Could we not? `.ravel()` is everywhere and it matches `ravel_multi_index` and `unravel_index`.___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
On Wed, Jan 9, 2019 at 10:55 PM Eric Wieser wrote: > 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. > I don't really think those are valid arguments. Strings are not a namespace, and if you want to make the analogy then it's at best a namespace within the functions/methods that the strings apply to. Discoverability: what is valid input for a keyword is discovered pretty much exclusively by reading the docstring or html doc page of the function, and not the docstring of some random object in the numpy namespace. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
On Thu, Jan 10, 2019 at 11:21 AM Feng Yu wrote: > Hi Todd, > > I agree a flag is more suitable than classes. > > I would add another bonus of a flag than a function argument is to avoid > massive contamination of function signatures for a global variation of > behavior that affects many functions. > I like this suggestion. Copy behavior fits very nicely with existing flags (e.g. UPDATEIFCOPY, WRITEABLE) and avoids both namespace pollution and complication docstrings. Ralf > Yu > > On Wed, Jan 9, 2019 at 11:34 PM Todd wrote: > >> On Mon, Jan 7, 2019, 14:22 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 >>> >> >> I would prefer a flag for this. Someone can make an array read-only by >> setting `arr.flags.writable=False`. So along those lines, we could have a >> `arr.flags.copyable` flag that if set to `False` would result in an error >> of any operation tried to copy the data. >> >>> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
