The design for__array_function__ (see NEP-18) predates support for type checking in NumPy, but it isn't obvious to me that adding typing overloads for non-NumPy arrays is a good idea. This is particularly true for NumPy APIs acting on types like pandas.DataFrame which intentionally deviate from the design of NumPy and only implement an incomplete subset of its design.

Generally speaking my recommendation would be not to try to combine type checking and__array_function__. There is basically no way to guarantee type safety here given its highly dynamic design. The__array_module__ API is a much saner (but more limited) approach here.

thanks for the feedback! i updated the PR title and description - they were outdated.

to clarify: this PR doesnot use__array_function__ at all. the approach is purely structural typing via a Protocol:

class_SupportsSplitOps(Protocol):defswapaxes(self,axis1:Any,axis2:Any,copy:Any= ...)->Any: ...def__getitem__(self,key:Any,/)->Any: ...

the split functions internally useswapaxes and slicing. for objects likeDataFrame that implement these methods and returnSelf, the type is preserved. this is just duck-typing - no__array_function__ dispatch involved.

the Protocol matches what the implementation actually does, so it should be type-safe for any object that properly implements these methods.

OK, interesting. I'm still hesitant to recommend relying on this behavior, but it's been around in NumPy long enough that it's probaby not going to change.

The real challenge is that strictly following the implementation, we don't know what the return type should be -- it could be an entirely different type, principle.

I would still suggest that anybody concerned with type safety should avoid these implicitly overloaded NumPy APIs. In retrospect, they were clearly a design mistake.

The primer error is unrelated

@jorenham thanks for taking a look and the great feedback. i resolved merge conflicts and i think addressed all your suggestions