Mailing List Archive

Antoine Pitrou <pitrou@free.fr> added the comment:

Why not name the parameter buffering=False rather than nobuffer=True?
Sounds more "natural" to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:

Yes, if you think so. But my intention was to indicate that
the "nobuffering" is a special feature the user can turn off to resort
to what could be considered normal, buffered, behaviour.

But either way is fine, and I'll be happy to change it.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:

Checked in as revision: 68532

----------
resolution: -> accepted
status: open -> closed

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Benjamin Peterson <benjamin@python.org> added the comment:

Kristján, could you merge this change into the Py3k branch, please?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:

Adding crossref to http://bugs.python.org/issue4448 regarding the
porting of this feature to 3.1

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:

Checked in r69209 to py3k

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Amaury Forgeot d'Arc <amauryfa@gmail.com> added the comment:

This causes failures in test_urllib2net.

The fix is easy: a handful of
- self.assertTrue(u.fp._sock.gettimeout() is None)
+ self.assertTrue(u.fp.raw._sock.gettimeout() is None)

But doesn't this show a backward-incompatible change?
or is the _sock member an implementation detail anyway?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:

The socket.socket.makefile() now returns a quite different kind of
object, namely a SocketIO thing. This comes as a result of the IO
refactoring in 3.0.
The good side to this is that old and naughty apps have been forbidden
to access the _sock member directly. This was the reason that we had
to disable read buffering in 2.x: Some clients would read directly
from the socket, even though it was "hidden".

As for the test failure, I admit that I didn't enable the "network"
resource for the testsuite. Will fix.

Btw, test_xmlrpc_net.py fails, because time.xmlrpc.com doesn't
resolve. Are there any other good and stable rpc servers out there?

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:

I'm afraid I misunderstood the problem.
Yes, since u.fp is now a io.BufferedReader() rather than a socket.Socket
(), the _sock member has moved.

But looking at the other assertions in test_urllib2net.py, you can see
the different ways the code uses to get at the socket: There is
u.fp.raw._sock and there is u.fp.fp.raw._sock.

IMHO I think we have to assume the _sock member to be an implementation
detail that is not part of the interface.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com