Option 4: Roll back __array_function__ changes and postpone them till after we drop python 2, where inspect.signature is guaranteed to exist

Testing suggests that this would fix the Dask issue, but something else appears to be causing the pandas issue -- #12226 didn't fix it.

@eric-wieser Unfortunately, the mere availability of inspect.signature would not be enough -- it actually has to always be used instead of inspect.getfullargspec. This seems unlikely to be the case for at least some time.

I guess the point of waiting for python3 only is that option (1) becomes more palatable - we can tell users how to solve the introspection problem.

p.s. There may be some independent value in not rolling out something major for our last python2 version, which perhaps argues for waiting. Or, maybe more crazily, one could proceed with the wrapper not doing anything by default, i.e., have one release in which even having __array_function__ is strictly opt-in (there was some discussion about this on the mailing list).

I finally understand exactly what the decorator library is doing.

It dynamically creates a function with the appropriate signature, e.g., for np.sum it could create:

def sum(a, axis=None, dtype=None, out=None, keepdims=np._NoValue, initial=np._NoValue):
    return _public_api_for_sum(a, axis, dtype, out, keepdims, initial)

where _public_api_for_sum is the public_api function that calls dispatcher and array_function_implementation_or_override (defined inside array_function_dispatch).

The problem with this version of the decorator is that inevitably this breaks extensibility -- implementations of np.sum will always need to know how to handle all the optional arguments for np.sum. This feels like a real non-starter, because it makes these overrides much harder to use.

So I think I'm -1 on using decorator now.

I guess the point of waiting for python3 only is that option (1) becomes more palatable - we can tell users how to solve the introspection problem.

Yeah, I'm starting to come around to this option. Another option would be to point users to the inspect.signature backport found in funcsigs.

@shoyer did you delete your own comment from 5 hours ago? I was going to respond to it, but it's not here anymore.

Or, maybe more crazily, one could proceed with the wrapper not doing anything by default, i.e., have one release in which even having array_function is strictly opt-in (there was some discussion about this on the mailing list).

Not crazy - that seems much better than removing everything and putting it back after the 1.16.x branch

@rgommers It looks like my comment is still there? Maybe some temporary glitch related to the GitHub data outage last night?

Or, maybe more crazily, one could proceed with the wrapper not doing anything by default, i.e., have one release in which even having array_function is strictly opt-in (there was some discussion about this on the mailing list).

Not crazy - that seems much better than removing everything and putting it back after the 1.16.x branch

Yes, if there is no way avoid breaking some edge cases it is certainly better to roll this out slowly. It would be a reasonable use-case for @njsmith's NUMPY_EXPERIMENTAL_ARRAY_FUNCTION environment variable.

I think we can close this, as we have the signature works and the discussion was: On python 3 that will fix it, Python 2 is a problem... But Python 2 isn't a problem anymore.