On Mon, Dec 8, 2008 at 12:07 PM, <[EMAIL PROTECTED]> wrote: > On Mon, 8 Dec 2008 at 11:25, Guido van Rossum wrote: >> >> On Mon, Dec 8, 2008 at 10:34 AM, <[EMAIL PROTECTED]> wrote: >>> >>> I'm in favor of an option to control what happens. >>> >>> I just really really don't want the _default_ to be "ignore". Defaulting >>> to a warning is fine with me, as would be defaulting to a traceback. >>> >>> But defaulting to "silently ignore", as we have now, is just asking for >>> user >>> confusion and debugging headaches, as detailed by Toshio. A _worse_ user >>> experience, IMO, than having a program fail when undecodable filenames >>> match the selection criteria. >> >> Do you really not care about the risk where apps that weren't written >> to be prepared to handle this will be rendered completely useless if a >> single file in a directory has an unencodable name? This is similar to >> an issue that Python had for a long time where it wouldn't start up if >> the current directory contained non-ASCII characters. > > No, I do care. In another message I agreed with you that having the > ap not fail was a reasonable goal. What I'm saying is that having it > ignore the undecodable files fail _silently_ is bad. And not picking > up a file that matches some selection criteria (ex: *.py) because it is > undecodable is a _failure_, in my opinion, that is _worse_ than getting > a traceback because there's an undecodable file in the directory. > > But I'm happy with just issuing a warning by default. That would mean > it doesn't fail silently, but neither does it crash. Seems like the > best compromise with the broken nature of the real world IT > environment.
OK, I can live with that too. >> Given that most developers will not have this issue in their own >> environment, most apps will not be prepared for this issue, and that >> makes it worse for the app's user! > > It is exactly because most developers won't have the issue in their own > environment that ignoring files silently is a problem. If they did, > they'd fix their code before it went out the door. Since they don't, > when their code is used by somebody in a mixed encoding environment, > the programs _will_ fail by ignoring files that they should process. > The question, it seems to me, is do they fail silently and mysteriously > by failing to process files they are supposed to, or do they fail with > at least a little bit of noise? A warning is fine. Whether the app *fails* or *succeeds* when the warning is issued depends on what the app is trying to do and what the user expects. There certainly are valid use cases for both, but I expect that succeeding noisily is going to be at least as common as failing (in the sense of not doing the right thing, not necessarily crashing) noisily. This is an improvement over always crashing. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
