[Zope-dev] Acquisition wrapped objects do not behave well on unicode call

Christian Zagrodnick cz at gocept.com
Tue Mar 1 14:57:03 EST 2011


On 2011-02-28 07:43:55 +0100, Christian Zagrodnick said:

> On 2011-02-25 21:56:49 +0100, David Glick said:
> 
>> On 2/20/11 1:32 AM, Christian Zagrodnick wrote:
>>> On 2011-02-19 17:17:44 +0100, Hanno Schlichting said:
>>> 
>>>> On Thu, Feb 17, 2011 at 8:27 AM, Christian Zagrodnick<cz at gocept.com>  wrote:
>>>>> On 2011-02-16 22:22:53 +0100, Hanno Schlichting said:
>>>>>>> svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called
Sure.
I'll>>>>>>>>>>> 
>>>>>>> 
> review, merge and release. Should be sometime this week,
>>>>>> cannot promise a day.
>>>> Branch reviewed, merged and released in Acquisition 2.13.6.
>>>> 
>>>> Could you remove the merged branch once you updated your buildout config?
>>> Done.
>>> 
>>> Thanks for releasing!
>> This change introduces a regression when calling unicode on wrapped
>> objects that implement __str__ but not __unicode__. Essentially it is
>> now doing the equivalent of str(aq_base(obj)) ... __str__ used to get a
>> wrapped object as 'self', but now it is unwrapped.
>> 
>> Here's a failing test that can be added to Acquisition's TestUnicode
>> test case to demonstrate the issue:
>> 
>> def test_str_fallback_is_still_wrapped(self):
>> class A(Acquisition.Implicit):
>> def __str__(self):
>> return str(len(Acquisition.aq_chain(self)))
>> wrapped = A().__of__(A())
>> self.assertEqual(u'2', unicode(wrapped))
>> 
>> This is currently causing some regressions in Plone tests.
> 
> I'll have a look at it. Thanks for spotting that.

Fixed in r120651 (trunk)

- Fixed bug: When an object did not implement ``__unicode__``, calling
  ``unicode(wrapped)`` was calling ``__str__`` with an unwrapped ``self``.

Is the situation with Plone better now?


-- 
Christian Zagrodnick · cz at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development




More information about the Zope-Dev mailing list