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]