rg3 <sarbalap+freshm...@gmail.com> added the comment: > > I have to correct myself. I applied the patch manually to my Python > > 2.6 installation. In Python 2.6, the line you moved is number 961, > > and I did the same change. > > OK. For information, you can apply it using the Unix "patch" command, > who can most of the time do all the work for you.
Yes, thanks, I already knew about "patch" but decided to apply the change manually just in case, as it belonged to a different Python branch. > That's expected, it's a consequence of this point I raised earlier: > > Note that I'm not sure why we need to wait for a further message on > > the control channel (maybe it's part of an RFC or something...). There's no doubt that not hanging is an improvement, but the current behavior somewhat defeats the purpose of an early call to "close". To get a broader view, the test case I provided is actually part of a much larger program. In that program, I read lines from the Slackware change log, stopping when I read a line that the program already knows about (because it caches the change log contents). This prevents the program from reading more than a single line if no new entries are present in the change log, but having to wait for the full file defeats the purpose, specially on slow dial-up connections. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11199> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
