[Zope-dev] zope.testbrowser and python2.7

[Jan-Jaap Driessen]

On 15 October 2010 11:49, Marius Gedminas <marius at gedmin.as> wrote:
> On Thu, Oct 14, 2010 at 07:19:17PM +0200, Jan-Jaap Driessen wrote:
>> The httplib.HTTPConnection API changed from python2.6 to python2.7.
>> These changes are reflected in the handleErrors property of
>> zope.testbrowser.browser.Browser - it is no longer possible to pass a
>> boolean into the request headers. A fix is available on the trunk of
>> zope.testbrowser [1]. In this implementation, a boolean is provided to
>> the consumers of the testbrowser API and a string is used in the
>> request headers.
>
> That seems sane.
>
>> This implementation is sub-optimal in my opinion.
>
> Why?

In my opinion, the booleanness of handling errors in the testbrowser
is expressed more elegantly by the presence/absence of a request
header than by converting a 'true'/'false' string to a boolean (and
reverse).

As Wolfgang however pointed out, the double negative in the
alternative solution is -1.

>> In the branch
>> 'janjaapdriessen-handle-errors' [2] you will find a cleaner
>> implementation, where the switch to handle_errors is controlled by the
>> presence of a "zope-do-not-handle-errors" header. The value of the
>> header is no longer interpreted. This change is backwards
>> incompatible.
>
> In what way?  This header is an internal zope.testbrowser implementation
> detail, isn't it?  Or do things like z3c.testbrowser also use it?

As far as I know it is an implementation detail.

> I'm -1 for breaking backwards compatibility.
>
>> Code relying on the 'x-zope-handle-errors' header will
>> break. I have tested this implementation against the ZTK trunk on
>> python2.7 and have found no breakage of this kind.
>
> It's times like this when I want to have a full checkout of everything
> in svn.zope.org (or, better yet, a search page on the web).
>
> Grepping in my shared buildout egg cache, I see that
> 'x-zope-handle-errors' appears in zope.testbrowser only.

I have also not found the x-zope-handle-errors in my local eggs.

> It is documented in the README as an API between testbrowser and the
> server it's testing, so I'm inclined to prefer the first,
> backwards-compatible solution.
>

Conclusion: with the -1*-1*-1 of Wolfgang and the -1 of Marius, I will
choose the first option.

Thank you for your feedback,

-- 
Jan-Jaap Driessen