On Fri, 5 Dec 2008 at 12:11, Guido van Rossum wrote:
On Fri, Dec 5, 2008 at 12:05 PM, Toshio Kuratomi <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt <[EMAIL PROTECTED]> wrote:
In 99% of all cases, using the default encoding will work and do what people
expect, which is why I would make this conversion automatic. In all other
cases, it will at least not fail silently (which would lead to garbage and
data loss) and allow more sophisticated applications to handle it.
I think the "always fail noisily" approach isn't the best approach.
E.g. if I am globbing for *.py, and there's an undecodable .txt file
in a directory, its presence shouldn't cause the glob to fail.
But why should it make glob() fail? This sounds like an implementation
detail of glob.
Glob was just an example. Many use cases for directory traversal
couldn't care less if they see *all* files.
I agree with Toshio. The only use case I can think of for not seeing
all files is when selecting a subset, and if the thing that does the
selecting only generates a traceback if a file that falls into the
subset is undecodable, then I don't see a problem. That is, if I'm
selecting a subset of the files in a directory, and one of that subset
is undecodable, I _want_ a traceback, because I'll be wanting _all_
of the files that match my selection criteria.(*)
So I'm curious to hear your use cases where undecodable files are
"don't care".
(*) More specifically, I want the program of a developer who didn't think
about the fact that users might have files with undecodable filenames
in their directory to generate a traceback rather than silently losing
those files. (This is spoken to both by the principle of least
surprise and the zen rule that errors should never pass silently :)
--RDM
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
