Repository navigation
ENH: call np.positive in ndarray.__pos__, and issue a deprecation warning when it falls #9081
Description
As I wrote in #8967 (comment):
Probably, the desired behavior is something like:
def __pos__(self):
try:
return np.positive(self)
except TypeError:
issue deprecation warning
return self.copy()(This may be a little tricky, though, because it will need to be done in C.)
This will be useful for ndarray subclasses that override __array_ufunc__.
Activity
eric-wieser commentedon May 10, 2017
I think you also want
if self.__array_ufunc__ != ndarray.__array_ufunc__in there, so that if__array_ufunc__raises an unrelatedTypeError, it's not just swallowednjsmith commentedon May 10, 2017
In fact, that could potentially replace the
TypeErrorcatch altogether?I don't think we'd even need to deprecate anything if we did it this way.
eric-wieser commentedon May 10, 2017
Difference would be that
__array_wrap__would never seenp.positive, but I don't think we care. So that does sound like a good solutionnjsmith commentedon May 10, 2017
Or more precisely,
__array_wrap__would see explicit calls tonp.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.shoyer commentedon May 10, 2017
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
TypeErrorif__array_ufunc__is not set. Something like:This would give us a path to eventually replacing the implementation with:
ngoldbaum commentedon May 23, 2017
I'll just say that it would be really nice if
np.positivewere invoked byoperator.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.eric-wieser commentedon May 23, 2017
@ngoldbaum: Although it's also really not hard for you to use
def __pos__(self): return np.positive(self)until this is fixed :)ngoldbaum commentedon May 23, 2017
I realize, it's just yet another corner case that an implementer of an ndarray subclass needs to deal with.
shoyer commentedon May 23, 2017
@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.
mhvk commentedon Jun 29, 2018
See #11450 for a fix.