[Zope3-dev] Zope3 vs CVS Python

[Guido van Rossum]

> I did have time to try it on Win2K today, and same thing:  testPipelining()
> + current CVS Python fails on Win98SE and Win2K whenever count > 1.  The
> failure mode is the same on both:
> 
> ======================================================================
> ERROR: testPipelining (Zope.Server.HTTP.tests.testHTTPServer.Tests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "C:\Code\Zope3\lib\python\Zope\Server\HTTP\tests\testHTTPServer.py",
>              line 174, in testPipelining
>     response_body = response.read(length)
>   File "C:\CODE\PYTHON\lib\httplib.py", line 431, in read
>     self.length = self.length - amt
> TypeError: unsupported operand type(s) for -: 'str' and 'int'
> 
> At this point, self.length contains the string 'UNKNOWN', and amt is 0.

You realize that 'UNKNOWN' is a constant in httplib.py and used to
initialize self.length, right?  (In __init__.)

It looks like the read() method is simply not expecting this when it
tests for "if self.length is not None" a few lines before line 431
(the crash point).

Hm, didn't you say that this doesn't fail under Python 2.2.1?  And
that it started failing about a month ago?  Maybe the recent changes
to socket.py or socketmodule.c for timeout sockets have broken this,
by changing the way buffering is done.  The HTTPResponse class uses
sock.makefile(), whose Windows implementation *did* change as part of
the timeout changes; and I don't have 100% faith in the changes.

You could try reverting socket.py to revision 1.19; this will break
the timeout feature, but AFAIK Zope doesn't use that, and it should
revert any changes introduced by that feature to the _fileobject class
returned (on Windows only) by s.makefile().

If that makes the failures go away, we can do a close reading of the
changes to _fileobject tomorrow.  (We'll make you a socket expert
yet. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)