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 <[email protected]>
<http://bugs.python.org/issue25458>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
