[twill] Bug in FakeResponse

John J Lee jjl at pobox.com
Thu Jun 28 14:32:46 PDT 2007


On Wed, 27 Jun 2007, Jacob Hallén wrote:
[...]
> As it turns out, there is a bug in mechanize as well.

I don't see a bug, actually.

I'll repeat: the mechanize code here is nasty, do not try and use your own 
response object.  I suspect you're missing the fact that mechanize 
response objects have independent seek pointers:

import copy

import mechanize

r = mechanize.make_response(
     "blah", [], "http://example.com/", 200, "OK")
data = r.read()
assert r.read() == ""
r2 = copy.copy(r)
data2 = r2.read()
assert data2 == data
assert r2.read() == ""


If you still think there's a bug, can you provide a specific failing test?


> My full fix for the problem is as follows:
> 
> 1. Re-implement FakeResponse:

Bad idea!


> 2. Modify the set_response method of the class RobustFactory:

> You have to make the copy before you do the response.read(), otherwise you
> have an exhausted stream in the copy you make.

Nope.


> Apparently analyzing forms worked at some point in time. I wonder how it 
> could be broken in two different places in two different packages.

The only bug I see is the one in twill, which is really my fault for the 
deeply obscure mechanize code here (the whole seek thing "fills a much 
needed gap", as does some of the backwards-compatibility of various kinds, 
which is one of the reasons has taken such a long time for mechanize to 
get to stable).


> I think some tests would be a good idea.

Any tests in particular?  You will have noticed that there are "some 
tests" already.

Certainly there aren't enough tests (especially functional tests).  I wish 
I could spend more time working on it...


John


More information about the twill mailing list