Blair <bidih...@gmail.com> added the comment:
I am not really the person (I don't know how Python is implemented) to
explain how the correct behaviour should be achieved (sorry). I do
appreciate that this may seem like exceptional behaviour. Numbers are a bit
different.
However, for what its worth, I think that the 'correct behaviour' was
implemented for subclasses of float and was working in Python 2.6, but not
now in 2.7. I don't know how the earlier implementation was done, but it
does work (I have used it to develop a nice little math library). Would
there be any documentation about the implementation?
I would say that the semantics do not need to apply to arbitrary Python
objects. The problem arises for numeric type subclasses when they are mixed
with non-subclassed numeric types.
In that case:
For 'x opn y' any binary operator (like +,*, etc), if (and only if) 'x' is
a built-in numeric type (int, long, float, complex) and 'y' is a subclass of
a built-in numeric type, then y.__ropn__(x) (if it exists) should be called
before x.__opn__(y).
If that were done, then subclasses of number types can implement commutative
operator properties. Otherwise, I don't think it works properly.
I see this as 'special' behaviour required of the int, long, float and
complex classes, rather than special behaviour for all Python objects.
If both 'x' and 'y' are subclasses of built in number types the required
behaviour seems too complicated to specify. I would be inclined to do
nothing special. That is, if both 'x' and 'y' are derived from built in
numeric classes (possibly different types) then x.__opn__(y) would be
called.
And should this apply to non-number types? I think not. Numbers deserve
special treatment.
I hope this helps.
On Mon, Nov 29, 2010 at 9:48 AM, Mark Dickinson <rep...@bugs.python.org>wrote:
>
> Changes by Mark Dickinson <dicki...@gmail.com>:
>
>
> Removed file: http://bugs.python.org/file19859/unnamed
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue5211>
> _______________________________________
>
----------
Added file: http://bugs.python.org/file19861/unnamed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
I am not really the person (I don't know how Python is implemented) to
explain how the correct behaviour should be achieved (sorry). I do appreciate
that this may seem like exceptional behaviour. Numbers are a bit different.<br>
<br>However, for what its worth, I think that the 'correct behaviour'
was implemented for subclasses of float and was working in Python 2.6, but not
now in 2.7. I don't know how the earlier implementation was done, but it
does work (I have used it to develop a nice little math library). Would there
be any documentation about the implementation?<br>
<br>I would say that the semantics do not need to apply to arbitrary Python
objects. The problem arises for numeric type subclasses when they are mixed
with non-subclassed numeric types. <br><br>In that case:<br><br>For 'x
opn y' any binary operator (like +,*, etc), if (and only if)Â 'x'
is a built-in numeric type (int, long, float, complex) and 'y' is a
subclass of a built-in numeric type, then y.__ropn__(x) (if it exists) should
be called before x.__opn__(y).<br>
<br>If that were done, then subclasses of number types can implement
commutative operator properties. Otherwise, I don't think it works
properly.<br><br>I see this as 'special' behaviour required of the int,
long, float and complex classes, rather than special behaviour for all Python
objects.<br>
<br>If both 'x' and 'y' are subclasses of built in number types
the required behaviour seems too complicated to specify. I would be inclined to
do nothing special. That is, if both 'x' and 'y' are derived
from built in numeric classes (possibly different types) then x.__opn__(y)
would be called.<br>
<br>And should this apply to non-number types? I think not. Numbers deserve
special treatment.<br><br>I hope this helps.<br><br><div class="gmail_quote">On
Mon, Nov 29, 2010 at 9:48 AM, Mark Dickinson <span dir="ltr"><<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left:
1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
Changes by Mark Dickinson <<a
href="mailto:dicki...@gmail.com";>dicki...@gmail.com</a>>:<br>
<br>
<br>
</div>Removed file: <a href="http://bugs.python.org/file19859/unnamed";
target="_blank">http://bugs.python.org/file19859/unnamed</a><br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker <<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>><br>
<<a href="http://bugs.python.org/issue5211";
target="_blank">http://bugs.python.org/issue5211</a>><br>
_______________________________________<br>
</div></div></blockquote></div><br>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
