<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 6:54 PM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2020-04-09 at 13:52 +0200, Ralf Gommers wrote:<br>
> On Wed, Mar 4, 2020 at 1:22 AM Sebastian Berg <<br>
> <a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>><br>
> wrote:<br>
> <br>
> The NumPy version should normally be older than other libraries, and<br>
> if<br>
> > NumPy updates the API so do the downstream implementers.<br>
> > E.g. dask may have to provide multiple version of the same function<br>
> > depending on the installed NumPy version, but that seems OK to me?<br>
> <br>
> That seems unworkable, and I don't think any libraries do this.<br>
> Coupling<br>
> the semantics of a single Dask function to the installed numpy<br>
> version is<br>
> odd.<br>
<br>
Is it all that odd? Libraries (not array providers) already need to<br>
test for NumPy version occasionally due to API changes, so they also<br>
have two versions of the same thing around (e.g. a fallback).<br></blockquote><div><br></div><div>That's completely different, it's internal to a library and not visible to end users via different signatures/behavior.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This simply would move the burden to the array-object implementer to<br>
some degree. Assume that we have a versioned API in some form or<br>
another, it seems to me we either require:<br>
<br>
¬† ¬†module = np.get_array_module(..., api_version=2)<br></blockquote><div><br></div><div>Yes, this is the version I was thinking about.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
or define `module.__api_version__`.<br>
<br>
Where the latter means that sklearn/SciPy may have to check<br>
`__api_version__` on every function call, while currently such checks<br>
usually happen at import time. On the other hand, the former means that<br>
sklearn/scipy can only opt-in to new API after 3+ years easily?<br></blockquote><div><br></div><div>That's anyway the case, has very little to do with API versioning I think - it's simply determined by minimum NumPy version supported.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Saying that the NumPy version is what pins the api-version, is not much<br>
more than assuming/requiring that NumPy will be the least up-to-date<br>
package?<br>
<br>
Of course it is unworkable to get 100% right in practice but are you<br>
saying that because it seems like an impractical approach,</blockquote><div><br></div><div>Yes this, impractical and undesired.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> or because<br>
the API surface is currently so large that, of course, we will never<br>
get it 100% right (but that is generally true, nobody will be able to<br>
implement NumPy 100% compatible)?<br></blockquote><div><br></div><div>That's true too, we *don't want* anyone to start adding compat features for outdated or "wish we could deprecate" NumPy features.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
`__array_function__` has same issue? If we change our API, Dask has to<br>
catch up. </blockquote><div><br></div><div>Yes, that's true. The restricted API should be more stable than the whole NumPy API, otherwise no one will be able to be fully compatible.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If SciPy expects it to be the old version though (based on<br>
the NumPy import) it will incorrectly assume the old-api will be used.<br></blockquote><div><br></div><div>That's not incorrect unless it's a backwards-incompatible change, which should be rare.</div><div><br></div><div>Cheers,</div><div>Ralf</div><div><br></div></div></div>