One more concern about the fix (so that you don't assume I didn't think of this ;) ) - handling of errors signified by the end-of-transfer response.

Handling a response in a close handler prevents us from actually checking its code:
* destructors like a close handler cannot raise exceptions because that would disrupt the resource release process
* and they're routinely called from `finally', so an exception would mask the current one if there's any (it's impossible to check within a finally block if it was was called as a result of an exception - http://stackoverflow.com/questions/1611561/can-i-get-the-exception-from-the-finally-block-in-python).

Now,
* The errors where the transfer never starts are detected by `ntransfercmd' either when opening the socket (425) or checking the first response (55x)
  * an exception when opening the socket would result in the response not being read.
* The errors when the transfer ends prematurely
  * are either handled by the socket (connection reset/timeout)
  * or can be detected by checking data length against the real one if it's available <- these are not currently handled
    * if it results from the user closing the socket prematurely (426), it _should_ be ignored
    * otherwise, we can wrap recv(), too, and check the response if the underlying fn returns ''
* If the error is local (an exception is raised in other code), the server's response doesn't matter

Looks like fixing this part warrants a separate ticket, though it does affect which option to take at this step - it speaks in favor of wrapping the data socket.

I'll ask at python-dev for some feedback before I go any way.