Peter Pan added the comment: The problem in my example is ftplib reports a "226" response to command "NOOP" which is nonsense. ftplib received "226" before "ftp.sendcmd('NOOP')" was called.
Since "transfercmd()" returns a socket, ftplib was planned to allow for manual transfer socket handling, but it is currently unable to handle the asynchronous responses from the server when the transfer is done. This is a bug or design error. Multiple changes are needed to support manual transfer socket handling. I suggest the following: Since asynchronous responses from the server are possible on the command socket, "set_debuglevel(1)" must report them at once, but this would require multithreading. A good compromise is to debug print and clear any buffered status right before sending the next command. We also need a method to check the last status code, in order to know the result of the last manual transfer. ftplib has to store it separately as an attribute. New attribute ------------- this.last_status_code = None #has no effect to any command or debug output this.last_status_message New internal method ------------------- #loop: look for buffered status response; if present, print debug and assign this.last_status = buffer.pop() .unbuffer(): ... New user methods ---------------- #Set last status to None so we can use "get_last_status" to check/poll for the next one. .clear_last_status(): this.last_status_code = None this.last_status_message = "" return #Return the last status received from the server; if there is one on the buffer, unbuffer and return that. .get_last_status(): this.unbuffer() return [this.last_status_code, this.last_status_message] ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25458> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com