ptz added the comment:
As David suggested, it indeed seems to be a case of timing. When
telnetlib.Telnet(...) returns, the server still doesn't have the data cooked,
and read_very_eager() fetches nothing. So nothing here fails as such, it's just
that my 0 experience in network programming sho
Jack Diederich added the comment:
There was no test suite for telnetlib prior to 2.7/3.1 so it is easily possible
that this is a regression. If you can post a test case that fails or - even
better - a patch that passes where the current code fails I'd be very
appreciative.
--
nosy:
R. David Murray added the comment:
Well, perhaps when you ran the test with the sleep the target server had an
unusually long startup delay. If you are going to use read_very_eager you are
going to have to deal with the possibility of not getting back what you
expected, so it doesn't really
ptz added the comment:
Strange. I was certain that I tried inserting a time.sleep() in the function
and it still didn't work, but I tried it just now and it does work as expected.
Sorry, and thanks for your answer, at least I learned something.
--
R. David Murray added the comment:
Presumably the difference is that there is a pause between the two statement
executions at the interactive prompt (even if you cut and paste) that does not
exist in the function.
--
nosy: +r.david.murray
resolution: -> invalid
stage: -> committed/r
New submission from ptz :
In Python 2.4, Assuming we've imported telnetlib, the following works:
>>> f = telnetlib.Telnet("some_text_based_server")
>>> f.read_very_eager()
The last call outputs the text that the server outputs upon connection (e.g.
"login: ").
However, if we put this
