zope.testbrowser and python2.7
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. This implementation is sub-optimal in my opinion. 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. 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. Please let me know if either of these solutions is OK with you. If so, grant me pypi rights (my handle is 'janjaapdriessen') so I can release zope.testbrowser and get a step closer to making the ZTK run on python2.7. Thanks, -- Jan-Jaap Driessen 1) svn.zope.org/repos/main/zope.testbrowser/trunk 2) svn.zope.org/repos/main/zope.testbrowser/branches/janjaapdriessen-handle-errors
Hello, * Jan-Jaap Driessen <jdriessen@thehealthagency.com> [2010-10-14 19:19]:
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.
Thanks for looking into this. Forward compatibility is a good thing.
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. This implementation is sub-optimal in my opinion. 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.
I agree that the boolean-string translating is a bit ugly, but to be honest, I also don't not dislike the double negative in your alternative solution. ;-)
This change is backwards incompatible. 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.
I'm definitely fine with changing that header name if necessary, though. Since that's an implementation detail of zope.testbrowser, it should be nobody else's business, and your tests seem to confirm this -- excellent.
Please let me know if either of these solutions is OK with you. If so, grant me pypi rights (my handle is 'janjaapdriessen') so I can release zope.testbrowser and get a step closer to making the ZTK run on python2.7.
I don't have a *strong* opinion which serialization of that flag is less ugly. I'm leaning towards the trunk one (no double negatives), but either one is basically fine by me. I've given you pypi rights for zope.testbrowser. Wolfgang
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 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? 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. 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.
Please let me know if either of these solutions is OK with you. If so, grant me pypi rights (my handle is 'janjaapdriessen') so I can release zope.testbrowser and get a step closer to making the ZTK run on python2.7.
Someone gave you rights already. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
On 15 October 2010 11:49, Marius Gedminas <marius@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
On 15 October 2010 13:15, Jan-Jaap Driessen <jdriessen@thehealthagency.com> wrote:
On 15 October 2010 11:49, Marius Gedminas <marius@gedmin.as> wrote: ... snip ...
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.
The code in the testlayer of zope.app.wsgi uses this header. zope.testbrowser 3.10.3 fixes this; 3.10.3 is *more* backwards compatible than 3.10.2. -- Jan-Jaap Driessen
participants (3)
-
Jan-Jaap Driessen -
Marius Gedminas -
Wolfgang Schnerring