Title: deriveds don't support coerce
Type: Severity: normal
Components: Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: leosoto Nosy List: leosoto, pjenvey
Priority: Keywords:

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 

this breaks 2.5 test_descr.notimplemented
msg3410 (view) Author: Philip Jenvey (pjenvey) Date: 2008-08-09.01:39:15
I think 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:37leosotosetstatus: open -> closed
resolution: fixed
messages: + msg3412
2008-08-10 07:12:09leosotosetmessages: + msg3411
2008-08-09 01:39:16pjenveysetassignee: leosoto
messages: + msg3410
nosy: + leosoto
2008-06-20 08:02:20pjenveycreate