Am 27.09.2005 um 14:17 schrieb Aurélien Campéas:
BTW, what's this "insanity with coercion rules" that you mention -
can you expand a little on this ?
See http://docs.python.org/ref/coercion-rules.html
Excerpt:
===================
- Below, __op__() and __rop__() are used to signify the generic
method names corresponding to an operator; __iop__ is used for the
corresponding in-place operator. For example, for the operator `+',
__add__() and __radd__() are used for the left and right variant of
the binary operator, and __iadd__ for the in-place variant.
- For objects x and y, first x.__op__(y) is tried. If this is not
implemented or returns NotImplemented, y.__rop__(x) is tried. If this
is also not implemented or returns NotImplemented, a TypeError
exception is raised. But see the following exception:
- Exception to the previous item: if the left operand is an instance
of a built-in type or a new-style class, and the right operand is an
instance of a proper subclass of that type or class, the right
operand's __rop__() method is tried before the left operand's __op__
() method. This is done so that a subclass can completely override
binary operators. Otherwise, the left operand's __op__ method would
always accept the right operand: when an instance of a given class is
expected, an instance of a subclass of that class is always acceptable.
- When either operand type defines a coercion, this coercion is
called before that type's __op__() or __rop__() method is called, but
no sooner. If the coercion returns an object of a different type for
the operand whose coercion is invoked, part of the process is redone
using the new object.
===================
However, this is just an attempt at documenting the current behavior,
AFAIK there is no definite reference except for what CPython implements.
(I'm working on running [a subset of] Python in Smalltalk)
- Bert -
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
