in-place exponentiation incongruities

[Terry Reedy]

On 8/12/2012 7:55 AM, Giacomo Alzetta wrote:

> What I mean is: when you implement a new type as a C extension you
> have to provide special methods through the NumberMethods struct. In
> this struct both the power and in-place power operations have three
> arguments.

I am not really sure why the latter is true. Probably 'consistency' at 
the special method level, with __pow__. As Steven points out, it is not 
needed to implement normal Python code.

This is one area of Python where the design is a bit messy. I believe 
the very existence of __ipow__ is a matter of consistency than of known 
use cases. Guido was not sure which __ixxx__ would ever be needed (for 
mutable objects), so he just put them all in.

At the Python level, both __pow__ and __ipow__ are also documented in 
the manual as having an optional, third, modulo parameter. __rpow__ is 
defined as binary, but that is a mistake

 >>> int.__rpow__(3, 5, 4)
1


> Now, suppose I implement the three argument variant of the
> in-place power in a class.

Are you actually planning to do this, or is this purely theoretical?

> No user would be able to call my C
> function with a non-None third argument,

Not true. Whether the function is coded in Python or C
cls.__ipow__(base, exp, mod) # or
base.__ipow__(exp, mod)

> while he would be able to
> call the normal version with the third argument.

That can also be done directly
 >>> int.__pow__(5, 3,  4)
1

-- 
Terry Jan Reedy