[PEAK] ObjectWrapper subclasses always callable

[Marcin Tustin]

I'm wrapping an object to pass to a django form, to alter how it is
displayed in the form. Django's form rendering code has the code:
if callable(data):
    data = data()

This breaks when passed the proxy object, because the underlying object is
not callable.

On Wed, May 23, 2012 at 7:01 PM, PJ Eby <pje at telecommunity.com> wrote:

> On Wed, May 23, 2012 at 11:25 AM, Marcin Tustin <marcin.tustin at gmail.com>wrote:
>
>> Python 2.7.2
>>
>>
>> On Wed, May 23, 2012 at 4:23 PM, PJ Eby <pje at telecommunity.com> wrote:
>>
>>>
>>> On May 23, 2012 10:39 AM, "Marcin Tustin" <marcin.tustin at gmail.com>
>>> wrote:
>>> >
>>> > I've found that instances of ObjectWrapper (and any subclasses) are
>>> always callable (the callable function returns True), notwithstanding that
>>> the __subject__ is not callable. Is there a way to remedy this?
>>> >
>>> > I've tried deleting the __call__ method, creating empty slots,
>>> creating my own call method, then trying to delete, using del or delattr on
>>> the subclass object, and creating a custom __getattribute__, all to no
>>> avail.
>>>
>>> Which Python version are you using?
>>>
>>
>> Okay, I've verified that this happens all the way back to 2.3, so that's
> not it.  (I think that maybe Python 3 uses hasattr(__call__) as its
> callable() implementation, but I'm not sure.)
>
> It looks like the only way for me to fix this is with a major revision:
> change the base classes to not have a __call__ slot, and dynamically change
> type at runtime to a subclass with a __call__ slot, if and only if their
> subject is callable...  and to somehow change if the subject changes.  (Not
> really sure how that's going to work.)
>
> What's the use case for this?  What code is using callable(), and can you
> convince its author to use hasattr instead?  ;-)
>
>
>


-- 
Marcin Tustin
Tel: 07773 787 105
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eby-sarna.com/pipermail/peak/attachments/20120523/01ef95cb/attachment.html