3-arg float pow()

Gareth McCaughan Gareth.McCaughan at pobox.com
Wed Sep 5 23:46:42 CEST 2001

Tim Peters wrote:

[I suggested some changes to error messages...]
> Sure!  These were changed, to
>     pow() 3rd argument cannot be 0
>     pow() 2nd argument cannot be negative when 3rd argument specified
>     pow() 3rd argument not allowed unless all other arguments are integers

I agree with John Baxter that "all" in the third of these
seems a little odd. Delete the second occurrence of the
substring " all" and it will improve. :-)

> > Oh, one other thing. Giving a third argument of 0 should
> > probably be equivalent to giving a third argument of None
> Sorry, not a chance.  You can make up any argument you want, but it remains
> 100x more likely that someone doing
>     pow(i, j, k)
> when k is 0 has made an error than that they're trying to exploit some
> clever argument, of which, as you say:

I thought this would be the answer. :-)

> > I don't think any programming language agrees with me...
> > (Rationale:
> >
> >   - "x % y" means "the smallest thing that's congruent to x
> >     modulo y", for some interpretation of "smallest".
> Not in Python.  x % y means divmod(x, y)[1] in Python, and divmod(x, y) is a
> pair (q, r) such that q*y + r == x and abs(r) < abs(y) (and the strict
> inequality there is part of what "smallest" means in Python).

That isn't a complete description of what Python does
(it couldn't be, since it doesn't determine the answer
uniquely), and I assure you that Python's behaviour
fits what I meant by "some interpretation of `smallest'",
though perhaps I was too terse there.

> I understand the argument.  Still no chance <wink>.  Forget that it violates
> abs(r) < abs(y) whenever abs(x) >= abs(y):  of what *use* is this?  I can't
> imagine a real algorithm where a single line
>     pow(x, y, z)
> *sometimes* wants to do a modular pow and sometimes not -- and even if I
> could, I can get that now via setting z to None.

I bet number theorists would sometimes want that. But,
really, I agree with you. (I'd still *prefer* things the
way I suggested, but I don't really think Python should
change to accommodate this preference.)

Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc

More information about the Python-list mailing list