ptz ppt...@gmail.com 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
Jack Diederich jackd...@gmail.com 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.
New submission from ptz ppt...@gmail.com:
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
R. David Murray rdmur...@bitdance.com 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
ptz ppt...@gmail.com 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 rdmur...@bitdance.com 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,
