[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/)