Meador Inge <mead...@gmail.com> added the comment:
Mark,
Is this still of interest?
I found the relevant changes in py3k, but I am not sure it is the behavior that
gumtree is expecting. Since py3k removes coercion completely, the test case
from issue 3734 would just issue:
Traceback (most recent call last):
File "test-5211.py", line 34, in <module>
print type(z + xz)
File "test-5211.py", line 5, in __coerce__
t = complex.__coerce__(self,other)
AttributeError: type object 'complex' has no attribute '__coerce__'
Where as I think gumtree wants the xcomplex case to behave as the xfloat case,
e.g.
<class '__main__.xfloat'>
<class '__main__.xcomplex'>
Since coercion is getting axed in py3k, I don't think it makes sense to provide
this behavior.
On the other hand, as you mentioned, the removal of coercion from complex could
be backported. However, if we are going to do that then we might as well just
backport the whole removal of coercion instead of just the bits from
'complexobject.c'. Bascially checkins r51431 and r58226.
----------
nosy: +minge
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
