Changes between Initial Version and Version 1 of Ticket #103, comment 1


Ignore:
Timestamp:
Feb 6, 2016, 10:36:04 AM (5 years ago)
Author:
schwa
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #103, comment 1

    initial v1  
    1212  After all, if client code closes a file-like object, the client code assumes that it's done with the file and wouldn't expect that any resources could still be in an "open" state. So a timeout when getting a file-like object is probably more surprising than a timeout during "normal operation" without using file-like objects. That could be a reason to fix the problem here, even if not catching `EOFError`s in lots of other parts of the ftputil code.
    1313
    14 I just did a web search and found this [https://stackoverflow.com/questions/6818091/getting-eoferror-along-with-exceptions-when-using-ftplib interesting discussion on StackOverflow]. Together with the information in [https://bugs.python.org/issue1481036 CPython's ticket 148036] that `EOFError` is contained in `ftplib.all_errors` it seems that ftputil is already implicitly catching `EOFError`s in its context managers `ftplib_error_to_ftp_os_error` and `ftplib_error_to_ftp_io_error` in `ftputil.error`.
     14I just did a web search and found this [https://stackoverflow.com/questions/6818091/getting-eoferror-along-with-exceptions-when-using-ftplib interesting discussion on StackOverflow]. Together with the information in [https://bugs.python.org/issue1481036 CPython's ticket 148036] that `EOFError` is contained in `ftplib.all_errors` it appears that ftputil is already implicitly catching `EOFError`s in its context managers `ftplib_error_to_ftp_os_error` and `ftplib_error_to_ftp_io_error` in `ftputil.error`.
    1515
    1616As it happens, `_available_child` uses a direct `host._session.pwd()` call (where `_session` usually is an `ftplib.FTP` instance) instead of the context managers.