[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