Ilhan Polat

Then should I leave it to you @j-bowhay ? I'm not sure how the deprecation tracker works so no problem for me if you take over.

This functionality is hardly a linalg thing. So I don't agree that it has to stay here. We need to separate array manipulation functions from actual linalg stuff. Transpose is...

These days I have been guilty of typing things a bit too terse and sound a bit pedestrian, so let me flesh out sentences a bit what I meant. Even...

> If that isn't SciPy, where else? Why not NumPy? It is already there. We are not removing from NumPy too. Only from `scipy.linalg`. > However, if there is a...

> but in that case we'd want a plan for it to be added to the standard. I think I don't follow this part. It is already in NumPy namespace....

OK I am definitely not following. How is array api relevant here? I am not even trying to start any discussion let alone that one in particular. It is already...

Yes that's perfectly fine and I get the argument. The argument I am failing to convey is that kron does not have to be in every package. This is not...

Ok let me try another way, kron was until now never meant to be in the array api right? So just because historically we had a bad version of it...

Put differently this function has no place in scipy.linalg because it is not a linalg function. It is an array creation function.

OK I am about to give up. First thing, we already agreed initially this function does not make sense here. Then Ralf comes in he says no, that's a bit...