Logged In: YES 
user_id=31435

Well, speaking as an old fp number-cruncher, mod makes 
little sense for floats on its own, and even less so 
combining it with pow (math.fmod makes sense for floats, 
but that's a different operation than the builtin float 
%).  As a practical matter, x%1.0 is sometimes used to get 
at the fractional bits of a float x >= 0, but I haven't 
seen that combined with pow (in practice -- "in theory" pow
(theta, n, 1.0) has interesting properties for irrational 
theta, but fp arithmetic isn't precise enough to exploit 
them).

OTOH, I can't doubt that some existing code uses integers 
that just happen to be in fp format, and then e.g. pow(3., 
4., 7.) makes as much sense as pow(3, 4, 7).  If you want a 
model where it's a number's value that matters-- not 
especially its type --that's worth preserving.  But 
then "something should be done about" stuff like this:

>>> pow(3., 500., 7.)
4.0
>>> pow(3, 500, 7)
2
>>>

So, as currently implemented, floats in 3-arg pow are 
surprising even when they denote whole integers.

3-arg pow makes clear sense for ints and longs when the 
power is non-negative, and compelling sense for "go fast" 
reasons, so I'd like to see it restricted to that.  We 
already complain about 3-arg pow with a complex argument.  
I haven't found any actual examples of 3-arg float pow on 
the web ... but who knows?  Let's break it in 2.a3 and see 
whether anyone screams?  I can ask on c.l.py too.