On Mon, 2021-07-05 at 11:17 -0700, Stefan van der Walt wrote:
On Mon, Jul 5, 2021, at 00:42, Ralf Gommers wrote:
I share your dislike, but I don't really see a better place where it doesn't make it even harder to spell, but I did just think of an alternative that may actually be quite reasonable: keep it private.
That would be fine. We haven't had this feature requested for many years, so as long as it is available in some shape or form it should satisfy the advanced users who need it. It also doesn't force us into a decision we cannot reverse (adding to the top-level API).
I am happy with (semi?)-private. Although, I would prefer a long-term goal we can work towards.
The reason why Gagandeep started working on this is so we can have the never-copy behavior in the `numpy.array_api` namespace. For the `asarray` function there, the `copy` keyword is still boolean, with description:
Whether or not to make a copy of the input. If ` True`, always copies. If ` False`, never copies for input which supports DLPack or the buffer protocol, and raises ` ValueError`` `in case that would be necessary. If ` None ` , reuses existing memory buffer if possible, copies otherwise. Default: ` None`.
In the end I think that's better than strings, and way better than enums - we just can't have that in the main namespace, because we can't change what `False` does.
If we can converge on this as an ideal API, should we really keep `copy=False` around without a warning? And if tag on a warning, maybe we may as well migrate NumPy itself (excruciatingly slow if necessary)? We seem to find some principle to dislike every single idea (I am probably forgetting a few): * Enums: * Namespace bloat * (Maybe clunky spelling) * Strings: * not strictly backward compatible (if accidentally used on old versions or potentially `__array_function__`.) * Slow to transition necessary * (Possibly not a good mix with `True/False` in general) * Transition `copy={True, False, None}`: * "Terrible API for a 3-way option" * some users have to update their code (libraries more than end-users, and libraries are easier to update). and I am honestly not sure that any of those is worrying. My preference would be to decide on the ideal API, and then move towards it. And if we don't think `CopyMode` is the right solution then it should be added only "semi-public": Probably with an underscore and documented to go away again, but allowing a pattern of: if np.__version__ > 1.22.0: if hasattr(np, "_CopyMode"): never_copy = np._CopyMode.NEVER else: never_copy = "never" else: # oops For libraries that need to work around transition difficulties. About a NEP: I am not sure we need one, although I am not opposed. It may make sense... Especially if whatever we converge on violates some written or unwritten "policy". However, I am wary to bring up a possible NEP if there is no clarity of where things are going. IMO, a NEP should be a concrete proposal, and that means that whoever writes it must have confidence in a proposal. If we transitioned from the brain-storming stage to a "formal decision making" one, then maybe a NEP is what we need. But, I currently don't know what the concrete proposal would be. Cheers, Sebastian
I agree < https://github.com/numpy/numpy/pull/19173#issuecomment-858226896> that this is a good API (although not everybody else does). < https://github.com/numpy/numpy/pull/19173#issuecomment-860314626>
W.r.t. NumPy's API: it could be okay to change the behavior of copy=False to make it more strict (no copies ever), because then at least errors will be raised and we can provide a message with instructions on how to fix it.
Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion