[Python-Dev] Bug in PyNumber_InPlacePower implementation?

Greg Ewing greg@cosc.canterbury.ac.nz
Wed, 29 May 2002 14:38:44 +1200 (NZST)

> This is exactly the same as what binary_op1() does.  I added this
> twist intentionally because of a use case where a subclass of a
> numeric type wants to override a binary (or ternary) operator defined
> by the base class.

I don't think you understand what I mean. I'm talking
about *in-place* operations. For in-place binary operations
we have, e.g.

INPLACE_BINOP(PyNumber_InPlaceSubtract, nb_inplace_subtract, nb_subtract, "-=")
                                        ^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^

Both the in-place and non-in-place slots are passed to
binary_iop, which uses the in-place slot for the first 
operand and the non-in-place slot for the second.

But ternary_op only gets *one* slot passed to it, which it
uses for everything. When doing an in-place ternary op,
this is the in-place slot. What this seems to mean is
that, if we have isinstance(a, A) and isinstance(b, B)
and issubclass(B, A), then

  a **= b

has the potential to in-place-modify b instead of a!

It seems to me that there ought to be a ternary_iop
routine that does for ternary ops what binary_iop does
for binary ones.

> Do you have a use case where this does the wrong thing, or is this
> just a theoretical musing?

It's a theoretical musing that came out of my attempts
to figure out whether, when one is implementing an
nb_inplace_power slot for a new type, the first argument
is guaranteed to "self". I need to know this so that Pyrex 
can do the right thing.

I've done some experiments with Python code, and it seems
to do the right thing in terms of calling the correct
__pow__, __rpow__ and __ipow__ methods. But I can't tell
from that what's really going on at the typeslot level.
I've looked at the code for the nb_inplace_power of
instance objects (the only example I can find of such
a method!), and it seems to assume that the first
argument is always "self". But I can't see how this is

In short, I'm confused!

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+