[issue5211] Fix complex type to avoid coercion in 2.7.

Blair report at bugs.python.org
Sun Nov 28 23:40:16 CET 2010


Blair <bidihall at 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 <report at bugs.python.org>wrote:

>
> Changes by Mark Dickinson <dickinsm at gmail.com>:
>
>
> Removed file: http://bugs.python.org/file19859/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5211>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19861/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
-------------- next part --------------
I am not really the person (I don&#39;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 &#39;correct behaviour&#39; was implemented for subclasses of float and was working in Python 2.6, but not now in 2.7. I don&#39;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 &#39;x opn y&#39; any binary operator (like +,*, etc), if (and only if)  &#39;x&#39; is a built-in numeric type (int, long, float, complex) and &#39;y&#39; 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&#39;t think it works properly.<br><br>I see this as &#39;special&#39; behaviour required of the int, long, float and complex classes, rather than special behaviour for all Python objects.<br>
<br>If both &#39;x&#39; and &#39;y&#39; 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 &#39;x&#39; and &#39;y&#39; 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">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</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 &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt;:<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 &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue5211" target="_blank">http://bugs.python.org/issue5211</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>


More information about the Python-bugs-list mailing list