I think you also want if self.__array_ufunc__ != ndarray.__array_ufunc__ in there, so that if __array_ufunc__ raises an unrelated TypeError, it's not just swallowed

In fact, that could potentially replace the TypeError catch altogether?

if self.__array_ufunc__ is not ndarray.__array_ufunc__:
    return np.positive(self)
else:
    return self.copy()

I don't think we'd even need to deprecate anything if we did it this way.

Difference would be that __array_wrap__ would never see np.positive, but I don't think we care. So that does sound like a good solution

Or more precisely, __array_wrap__ would see explicit calls to np.positive, but wouldn't see calls to __pos__ (just like today). And that's actually probably what we want, since we don't want to risk breaking existing __array_wrap__ users.

I don't think we'd even need to deprecate anything if we did it this way.

I also wanted to deprecate calls like +np.array(['foo']), which currently works but should really raise an error.

But we could switch to only catching TypeError if __array_ufunc__ is not set. Something like:

def __pos__(self):
    if self.__array_ufunc__ is not ndarray.__array_ufunc__:
        return np.positive(self)
    else:
        try:
            return np.positive(self)
        except TypeError:
            issue deprecation warning
            return self.copy()

This would give us a path to eventually replacing the implementation with:

def __pos__(self):
    return np.positive(self)

I'll just say that it would be really nice if np.positive were invoked by operator.pos. With __array_ufunc__ I've been able to remove all of the magic method overrides on my ndarray subclass except for the override for __pos__ due to this issue.

@ngoldbaum: Although it's also really not hard for you to use def __pos__(self): return np.positive(self) until this is fixed :)

I realize, it's just yet another corner case that an implementer of an ndarray subclass needs to deal with.

@ngoldbaum this logic is all pretty self-contained (I would start here), so implementing something like @njsmith's suggestion both would be straightforward. Contributions would certainly be welcome!

It would indeed be nice to get this into 1.13 before the final release.

See #11450 for a fix.