<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’ve generally been on the “let the NumPy devs worry about it” side of things, but I do agree with Ilhan that `like=` is confusing and `typeof=` would be a much more appropriate name for that parameter.<div class=""><br class=""></div><div class="">I do think library writers are NumPy users and so I wouldn’t really make that distinction, though. Users writing their own analysis code could very well be interested in writing code using numpy functions that will transparently work when the input is a CuPy array or whatever.</div><div class=""><br class=""></div><div class="">I also share Ilhan’s concern (and I mentioned this in a previous NEP discussion) that NEPs are getting pretty inaccessible. In a sense these are difficult topics and readers should be expected to have *some* familiarity with the topics being discussed, but perhaps more effort should be put into the context/motivation/background of a NEP before accepting it. One way to ensure this might be to require a final proofreading step by someone who has not been involved at all in the discussions, like peer review does for papers.</div><div class=""><br class=""></div><div class="">Food for thought.</div><div class=""><br class=""></div><div class="">Juan.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 13 Aug 2020, at 9:24 am, Ilhan Polat <<a href="mailto:ilhanpolat@gmail.com" class="">ilhanpolat@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">For what is worth, as a potential consumer in SciPy, it really doesn't say anything (both in NEP and the PR) about how the regular users of NumPy will benefit from this. If only and only 3rd parties are going to benefit from it, I am not sure adding a new keyword to an already confusing function is the right thing to do. <br class=""></div><div class=""><br class=""></div><div class="">Let me clarify,</div><div class=""><br class=""></div><div class="">- This is already a very (I mean extremely very) easy keyword name to confuse with ones_like, zeros_like and by its nature any other interpretation. It is not signalling anything about the functionality that is being discussed. I would seriously consider reserving such obvious names for really obvious tasks. Because you would also expect the shape and ndim would be mimicked by the "like"d argument but it turns out it is acting more like "typeof=" and not "like=" at all. Because if we follow the semantics it reads as "make your argument asarray like the other thing" but it is actually doing, "make your argument an array with the other thing's type" which might not be an array after all. <br class=""></div><div class=""><br class=""></div><div class="">- Again, if this is meant for downstream libraries (because that's what I got out of the PR discussion, cupy, dask, and JAX were the only examples I could read) then hiding it in another function and writing with capital letters "this is not meant for numpy users" would be a much more convenient way to separate the target audience and regular users. numpy.astypedarray([[some data], [...]], type_of=x) or whatever else it may be would be quite clean and to the point with no ambiguous keywords.</div><div class=""><br class=""></div><div class="">I think, arriving to an agreement would be much faster if there is an executive summary of who this is intended for and what the regular usage is. Because with no offense, all I see is "dispatch", "_array_function_" and a lot of technical details of which I am absolutely ignorant. <br class=""></div><div class=""><br class=""></div><div class="">Finally as a minor point, I know we are mostly (ex-)academics but this necessity of formal language on NEPs is self-imposed (probably PEPs are to blame) and not quite helping. It can be a bit more descriptive in my external opinion.</div><div class=""><br class=""></div><div class="">best,</div><div class="">ilhan</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 12:18 AM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank" class="">ralf.gommers@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 10, 2020 at 8:37 PM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net" target="_blank" class="">sebastian@sipsolutions.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2020-08-10 at 17:35 +0200, Hameer Abbasi wrote:<br class="">
> Hi,<br class="">
> <br class="">
> We should have a higher-bandwidth meeting/communication for all<br class="">
> stakeholders, and particularly some library authors, to see what<br class="">
> would be good for them.<br class=""></blockquote><div class=""><br class=""></div><div class="">I'm not sure that helps. At this point there's little progress since the last meeting, I think the plan is unchanged: we need implementations of all the options on offer, and then try them out in PRs for scikit-learn, SciPy and perhaps another package who's maintainers are interested, to test like=, __array_module__ in realistic situations.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br class="">
> We should definitely have language in the NEP that says it won’t be<br class="">
> in a release unless the NEP is accepted.<br class="">
<br class="">
In that case, I think the important part is to have language right now<br class="">
in the implementation, although that can refer to the NEP itself of<br class="">
course.<br class="">
You can't expect everyone who may be tempted to use it to actually read<br class="">
the NEP draft, at least not without pointing it out.<br class=""></blockquote><div class=""><br class=""></div><div class="">Agreed, I think the decision is on this list not in the NEP, and to make sure we won't forget we need an issue opened with the 1.20 milestone.</div><div class=""><br class=""></div><div class="">Cheers,<br class=""></div><div class="">Ralf</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
I will say that I think it is not very high risk, because I think<br class="">
annoying or not, the argument could be deprecated again with a<br class="">
transition short phase. Admittedly, that argument only works if we have<br class="">
a replacement solution.<br class="">
<br class="">
Cheers,<br class="">
<br class="">
Sebastian<br class="">
<br class="">
<br class="">
> <br class="">
> Best regards,<br class="">
> Hameer Abbasi<br class="">
> <br class="">
> --<br class="">
> Sent from Canary (<a href="https://canarymail.io/" rel="noreferrer" target="_blank" class="">https://canarymail.io</a>)<br class="">
> <br class="">
> > On Monday, Aug 10, 2020 at 5:31 PM, Sebastian Berg <<br class="">
> > <a href="mailto:sebastian@sipsolutions.net" target="_blank" class="">sebastian@sipsolutions.net</a> (mailto:<a href="mailto:sebastian@sipsolutions.net" target="_blank" class="">sebastian@sipsolutions.net</a>)><br class="">
> > wrote:<br class="">
> > Hi all,<br class="">
> > <br class="">
> > as a heads up that Peter Entschev has a PR open to add `like=` to<br class="">
> > most array creation functions, my current plan is to merge it soon<br class="">
> > as a preliminary API and bring it up again before the actual<br class="">
> > release (in a few months). This allows overriding for array-likes,<br class="">
> > e.g. it will allow:<br class="">
> > <br class="">
> > <br class="">
> > arr = np.asarray([3], like=dask_array)<br class="">
> > type(arr) is dask.array.Array<br class="">
> > <br class="">
> > This was proposed in NEP 35:<br class="">
> > <br class="">
> > <a href="https://numpy.org/neps/nep-0035-array-creation-dispatch-with-array-function.html" rel="noreferrer" target="_blank" class="">https://numpy.org/neps/nep-0035-array-creation-dispatch-with-array-function.html</a><br class="">
> > <br class="">
> > Although that has not been accepted as of now, the PR is:<br class="">
> > <br class="">
> > <a href="https://github.com/numpy/numpy/pull/16935" rel="noreferrer" target="_blank" class="">https://github.com/numpy/numpy/pull/16935</a><br class="">
> > <br class="">
> > <br class="">
> > This was discussed in a smaller group, and is an attempt to see how<br class="">
> > we<br class="">
> > can make the array-function protocol viable to allow packages such<br class="">
> > as<br class="">
> > sklearn to work with non-NumPy arrays.<br class="">
> > <br class="">
> > As of now, this would be experimental and can revisit it before the<br class="">
> > actual NumPy release. We should probably discuss accepting NEP 35<br class="">
> > more. At this time, I hope that we can put in the functionality to<br class="">
> > facilitate this discussion, rather the other way around.<br class="">
> > <br class="">
> > If anyone feels nervous about this step, I would be happy to<br class="">
> > document<br class="">
> > that we will not include it in the next release unless the NEP is<br class="">
> > accepted first, or at least hide it behind an environment variable.<br class="">
> > <br class="">
> > Cheers,<br class="">
> > <br class="">
> > Sebastian<br class="">
> > <br class="">
> > _______________________________________________<br class="">
> > NumPy-Discussion mailing list<br class="">
> > <a href="mailto:NumPy-Discussion@python.org" target="_blank" class="">NumPy-Discussion@python.org</a><br class="">
> > <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank" class="">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br class="">
> <br class="">
> _______________________________________________<br class="">
> NumPy-Discussion mailing list<br class="">
> <a href="mailto:NumPy-Discussion@python.org" target="_blank" class="">NumPy-Discussion@python.org</a><br class="">
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank" class="">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br class="">
<br class="">
_______________________________________________<br class="">
NumPy-Discussion mailing list<br class="">
<a href="mailto:NumPy-Discussion@python.org" target="_blank" class="">NumPy-Discussion@python.org</a><br class="">
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank" class="">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">
NumPy-Discussion mailing list<br class="">
<a href="mailto:NumPy-Discussion@python.org" target="_blank" class="">NumPy-Discussion@python.org</a><br class="">
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank" class="">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br class="">
</blockquote></div>
_______________________________________________<br class="">NumPy-Discussion mailing list<br class=""><a href="mailto:NumPy-Discussion@python.org" class="">NumPy-Discussion@python.org</a><br class="">https://mail.python.org/mailman/listinfo/numpy-discussion<br class=""></div></blockquote></div><br class=""></div></body></html>