Issue1060
Created on 2008-06-20.08:02:20 by pjenvey, last changed 2008-08-10.20:51:37 by leosoto.
|
| msg3294 (view) |
Author: Philip Jenvey (pjenvey) |
Date: 2008-06-20.08:02:09 |
|
__coerce__ (or maybe we need __coerce_ex__) is not defined in
PyObjectDerived
this breaks 2.5 test_descr.notimplemented
|
| msg3410 (view) |
Author: Philip Jenvey (pjenvey) |
Date: 2008-08-09.01:39:15 |
|
I think http://codereview.appspot.com/2854 will probably fix this, assigning to Leo
|
| msg3411 (view) |
Author: Leonardo Soto (leosoto) |
Date: 2008-08-10.07:12:08 |
|
I'm working on it. The biggest problem introduced by my patch is with
types that already expose __coerce__, such as PyInteger.
There, when the new PyIntegerDerived#__coerce_ex__ looks up for
'__coerce__' it finds the method exposed by PyInteger. This exposed
method (PyObject#int__coerce__) calls PyObject#__coerce__ which calls
the overriden __coerce_ex__ and we have an infinite loop.
[BTW, I'm reaching the point where I realized that no exposed method
should call virtual methods, either directly or indirectly. Otherwise
this kind of unintended interactions happen.]
I plan to refactor PyObject#__coerce__ slightly, so
PyInteger#int__coerce__ (and other exposed coerce methods) don't need to
call (indirectly) the virtual PyObject#__coerce_ex__ method.
|
| msg3412 (view) |
Author: Leonardo Soto (leosoto) |
Date: 2008-08-10.20:51:35 |
|
Fixed in r5133 (asm branch). However, as pointed out previously, 2.5
test-descr is still broken.
|
|
| Date |
User |
Action |
Args |
| 2008-08-10 20:51:37 | leosoto | set | status: open -> closed
resolution: fixed
messages:
+ msg3412 |
| 2008-08-10 07:12:09 | leosoto | set | messages:
+ msg3411 |
| 2008-08-09 01:39:16 | pjenvey | set | assignee: leosoto
messages:
+ msg3410
nosy:
+ leosoto |
| 2008-06-20 08:02:20 | pjenvey | create | |
|
