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
_______________________________________________
twill mailing list
[email protected]
http://lists.idyll.org/listinfo/twill
