Python 3.3 redesigned the exception hierarchy to be able to catch a
specific exception class instead of catching OSError or IOError and
checking error codes (see PEP
3151). Note that IOError
was aliases with OSError.
At the moment, ftputil only supports the older approach - catching broad
exceptions and checking errno - because before version 4.0.0 ftputil
needed to support Python 2.6 and up. On the other hand, the new
exception classes were only introduced in Python 3.3. Since ftputil
4.0.0 targets Python 3.5 and up, it's now safe to use the new exception
hierarchy.
This ticket should be implemented for ftputil 4.0.0 because it may break backward compatibility in some cases. Similar to what PEP 3151 discusses, "careful" code using ftputil 3.4 and earlier should continue to work without changes.
Implementing this ticket probably is practically impossible for several reasons:
Error reporting granularity
FTP server return codes aren't nearly as granular as errors for the local file system. For example, I'd expect that if you run
ftp_host.mkdir("/path/to/make"), you'd get an error 550, which could mean any of:
- The directory
/path/todoesn't exist- The directory
/path/to/makealready exists- We have no write permission in
/path/toIn contrast, as I understand the PEP, all three cases would raise different exceptions for a local file sysem operation.
You might argue that we can work around this by doing more checks. For example, we could explicitly check the existence of
/path/toin the above example. This won't work because we'd still getFalsealso for the case that we don't have read permission for/path. Also checking lots of conditions would slow down FTP operations and complicate the ftputil code a lot.Checking error messages
We could think of examing the text that comes with a server error, say, "550: no such file or directory". I think this is futile because different servers will use different wordings for error messages. This is bound to break.
Moreover, some servers may even report messages in other languages than English. During the lifetime of ftputil I've seen at least one FTP server that reported errors in Spanish. (In itself this is of course fine, but it would totally break guesses of error causes.)
This approach obviously is an uphill battle.
Conclusion
To me it doesn't seem realistic that this ticket can be implemented with reasonable effort. Therefore I close it.
Although the goal of ftputil is having similar APIs for local file systems and for FTP servers, the two systems are so different that sometimes this similarity/compatibility isn't achievable. (We already have some incompatibilities in stat results, like missing group ids or limited timestamp precision.)