[Python-Dev] Bug in PyNumber_InPlacePower implementation?
Guido van Rossum
guido@python.org
Wed, 29 May 2002 23:29:16 -0400
> Guido:
>
> > GregE:
> > > a **= b
> > >
> > > has the potential to in-place-modify b instead of a!
> >
> > Not quite -- the arguments won't be reversed, but it may call B's
> > inplace power function with an A instance as the first argument.
>
> Hmmm, I see. I guess it's just a matter of being aware
> that this can happen and doing the necessary type tests.
>
> > This can return NotImplemented if it doesn't know what to do
> > in that case.
>
> Although if you're implementing inplace-power you're
> probably also implementing non-inplace-power, in which case
> the right thing is probably to call that instead. I
> don't think that will happen automatically if you
> return NotImplemented -- or will it?
For binary ops it will (see binary_iop()). But because the ternary
code doesn't have the inplace support, it won't.
> > It's a pretty esoteric case ... The correct code would
> > be pretty hairy I think (the non-inplace ternary is hairy enough).
>
> I think the existing ternary_op routine could be converted
> fairly easily into one that could be used for both. Just pass
> in two slot arguments, and use one for the first arg and
> the other one for the second and third args. For non-inplace
> ops, call it with the non-inplace slot for both.
>
> It's not a big deal, I suppose, but it would be nice if
> it could be made consistent with the other in-place ops.
Do you care enough about this to supply a patch? I would apply it,
but I don't care enough to write it. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)