[Python-Dev] Python-3.0, unicode, and os.environ

[rdmurray at bitdance.com]

On Fri, 5 Dec 2008 at 12:11, Guido van Rossum wrote:
> On Fri, Dec 5, 2008 at 12:05 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
>> Guido van Rossum wrote:
>>> On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt <eckhardt at satorlaser.com> 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