Chris Withers ch...@simplistix.co.uk added the comment:
Yep, having done some more extensive profiling, it looks like my issue is
different: all the time is being spent in httplib's
HTTPResponse._read_chunked. That wouldn't be a symptom of this issue,
would it?
--
Gregory P. Smith g...@krypto.org added the comment:
Okay, I do not think this has been fixed yet. Anyone calling
getresponse() can indeed use buffering=True, it can mess things up if
the do not close the connection afterwards.
The addition of the sockbuf parameter to HTTPConnection as proposed
Chris Withers ch...@simplistix.co.uk added the comment:
Why not allow True or an integer as values for a buffer_size parameter
to the HTTPConnection constructor. False would be the default, which
would mean no buffering as currently is the case. True would mean use
buffering of the default
Gregory P. Smith g...@krypto.org added the comment:
Anything that adds a new parameter can not be backported to 2.6 as that
counts as an API change / feature addition.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2576
Gregory P. Smith g...@krypto.org added the comment:
trunk r74463 now forces the HTTPResponse with buffering=True to close
afterwards using a HTTPResponse._must_close flag similar to what was
suggested in buffered_socket.diff in this issue.
--
___
Gregory P. Smith g...@krypto.org added the comment:
I am also unable to reproduce the reported problem using the
pastebin.ca/973578 code. The time to download 400mb from localhost
remains the same regardless of buffering=False (default) or True.
The problem still exists but it is better
Changes by Gabriel Genellina gagsl-...@yahoo.com.ar:
--
nosy: +gagenellina
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2576
___
___
Gregory P. Smith g...@krypto.org added the comment:
Note that http://bugs.python.org/issue4879 may have already fixed this
problem in trunk r68532.
--
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2576
Chris Withers ch...@simplistix.co.uk added the comment:
I tried to use the following to change the buffersize for a download:
from base64 import encodestring
from httplib import HTTPResponse,HTTPConnection,HTTPSConnection,_UNKNOWN
from datetime import datetime
class
Antoine Pitrou pit...@free.fr added the comment:
I must admit I don't understand the conflict between buffering and
pipelined requests. This is all sequential reading and the buffer should
be transparent, shouldn't it?
--
nosy: +pitrou
versions: +Python 2.7, Python 3.1, Python 3.2
Chris Withers ch...@simplistix.co.uk added the comment:
Well, for me, buffer size doesn't appear to have made any difference...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2576
___
Changes by Ralf Schmitt [EMAIL PROTECTED]:
--
nosy: +schmir
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2576
__
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Diniz [EMAIL PROTECTED] added the comment:
Also reported in #1542407
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2576
__
___
Python-bugs-list mailing list
Facundo Batista [EMAIL PROTECTED] added the comment:
Daniel, Aren, please submit also what Daniel described, and I'll take a
look and push it forward.
Regards,
--
nosy: +facundobatista
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2576
Daniel Diniz [EMAIL PROTECTED] added the comment:
The code patch is trivial, he said, only to find out it was not :)
Facundo, thanks in advance for taking a look at this!
This patch tries to implement, document and test an optional argument to
HTTPConnection, which passes it to HTTPResponse.
New submission from Aren Olson [EMAIL PROTECTED]:
This is a reposting of issue 508157, as requested by gvanrossum.
The socket file object in httplib is opened without any buffering
resulting in very slow performance of read(). The specific problem is
in the httplib.HTTPResponse constructor.
Changes by Gregory P. Smith [EMAIL PROTECTED]:
--
priority: - high
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2576
__
___
Python-bugs-list mailing list
Daniel Diniz [EMAIL PROTECTED] added the comment:
The code patch is trivial. I believe it needs docs (both explaining how
to use and warning against the problems it may cause), a NEWS entry and
tests (at least to check what happens when an invalid value lands).
I can work on those changes if
18 matches
Mail list logo
