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