On Sun, 7 Dec 2008 at 13:33, Guido van Rossum wrote: > My problem with raising exceptions *by default* when an undecodable > name exists is that it may render an app completely useless in a > situation where the developer is no longer around. This happened all I think Nick Coghlan's suggestion of emitting warnings would be an excellent solution that addresses both your concerns and the concerns Toshio has expressed (and with which I agree 100%). The above is the only use case I've heard in this thread for ignoring files with names that can't be decoded: so that a user can use the program on those files whose names can be decoded even when the user does not have the resources to get the program fixed to handle undecodable filenames. I agree that that is a worthwhile goal. If warnings were emitted, then files would not be silently ignored, yet the program could still be used. --RDM PS: I'd like to see a similar warning issued when an access attempt is made through os.environ to a variable that cannot be decoded.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4