PEP0238: overriding // (__intdiv__) ??

[Guido van Rossum]

> In article <snatltotvlevdqc7kaj1m8v82o5fv51543 at 4ax.com>, Kirby Urner
> <urner at alumni.princeton.edu> writes
> >
> >Maybe I missed it.  Did the PEP specify what we'd use to override
> >the // operator in a class?  __intdiv__ and __rintdiv__ ?  Seems
> >we'd need something like this, to have our objects play along.  And
> >I'd think this wrinkle should become available simultaneously with
> >//.

I haven't picked the names yet, but yes, these will be available.
What about __wdiv__ (for whole division) and __rdiv__ (for real
division; or rational division of you please :-).

Robin Becker <robin at jessikat.fsnet.co.uk> writes:

> If and when the grand type class unification takes place and ints,
> longs, floats rationals and the like are all properly sub-classable,
> will it possible to inject behaviours into those types? If so then I
> can trivially change '/' by changing the base implementations for
> the various types.

No, changes to the existing built-in types will be forbidden, partly
for low-level practical reasons (the type objects are shared between
multiple interpreters in the same address space) and partly out of
principle (the effect is probably more global than you think,
affecting all library code you use, implicitly or explicitly).

> I suppose that there are efficiency arguments involved, but the
> compiler must issue a divide instruction anyhow and leave it up to
> the operand classes to decide what to do.

Yes, that's why there will be four new slots in the "as number"
substructure of the type object: one for //, one for
/-under-future-division, and two more for augmented assignment
involving these two operators.  (This is not yet in the patch I
provided on SF.) 

> That way we could begin to treat this as a properly abstract
> programming language. It could of course lead to utter confusion.

Indeed.

--Guido van Rossum (home page: http://www.python.org/~guido/)