Note, same answers except for type:

   2   + 2   = 4
   2.0 + 2.0 = 4.0
   2L  + 2L  = 4L

   2   * 2   = 4
   2.0 * 2.0 = 4.0
   2L  * 2L  = 4L

   2**2L     = 4L
   2.0**2L   = 4.0
   2.0**2    = 4.0

   etc.

   > >> 4L == 4 == 4.0  # check for equality
   1

   2   - 1   = 1
   2.0 - 1.0 = 1.0
   2L  - 1L  = 1L

   > >> 1L == 1 == 1.0  # check for equality
   1

But...

   1L/2L     = 0L
   1/2       = 0
   1.0/2.0   = 0.5

... division is special.

The other primitive ops return essentially the same answer
(as demonstrated by ==), regardless of type.  But not /.
/ is different.  Does it have to be?

   1L/2L   = 0.5
   1/2     = 0.5
   1.0/2.0 = 0.5

But what if we want the divmod(a,b)[0] integer behavior?

   1L//2L   = 0L
   1//2     = 0
   1.0//2.0 = 0

Now, if we see  var3 = var1/var2 in code, we know var3 is
a float.  We know this even if we don't know for sure what
var1 and var2 are.

This isn't so important with + - * and ** because the float
and non-float answers are essentially the same (baring overflow
when long oes beyond the range of int or float), but with /,
the answers are currently very different depending on argument
types.

Such gross differences in behavior would be better handled
by two different operators, such that code readibility is
not sacrificed to a primitive operator's low-level, tricky
polymorphism (you can still redefine / if you want to,
using __div__ and __rdiv__ -- you'll also be able to
override // -- then it's up to you to make clear to your
readers what you're up to).

Kirby


_______________________________________________
Edu-sig mailing list
Edu-sig@[...].org
http://mail.python.org/mailman/listinfo/edu-sig