I think this makes sense, at least for all but arange (for which I'd argue that it is already overly broad: it should just do integers...). As is, linspace already works with Quantity, while logspace cannot easily (hard to tell what log(1 m) would be; geomspace does not work with Quantity but could be adapted if a bit more thought was put in it.

Possibly a way to tell whether something should get an __array_function__ override is whether the arguments at least in principle could be arrays. For the *space functions, that is quite obviously true for start and stop (would need a new axis argument); for arange it is not.

I agree that at least in principle linspace() could accept arrays, e.g., by broadcasting start and stop against each other and then inserting a new dimension with the samples. (Maybe this should be an enhancement proposal?)

In any case, I see that linspace() uses asanyarray() internally. That's another rule of thumb to consider: any numpy function that casts its inputs using asarray() or asanyarray() should support overrides using __array_function__, too.

In principle perhaps arange() should only do integers but the ship sailed on that a long time ago. I'm not entirely happy support __array_function__ on arange(), but I do think users would be surprised if they can override linspace but not arange...

Agreed that casting to array is a dead giveaway for allowing __array_ufunc__!

Not sure about arange - on the one hand I don't really see how it hurts to allow overrides, on the other I recall a mess in discussions about what should happen for something as simple as complex numbers and feel we shouldn't make a (slightly) bad situation worse. So, I'd be quite happy too with explicitly noting that, really, here one does deal with a case where the arguments should be integers and certainly scalar, and that hence we won't extend it.

(Aside: the arange docstring is very python2 specific, stating that range returns a list... In some sense, one would like an arange object that auto-evaluates...)

I recall a mess in discussions about what should happen for something as simple as complex numbers

#10332

We never resolved what to do about arange

Will close this for now, since arange has the like= parameter right now. Maybe one day we want to change that, but most of this seems resolved one way or another and it seems easier to discuss it in a new issue.