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

Guido van Rossum guido at python.org
Mon Dec 8 20:25:18 CET 2008


On Mon, Dec 8, 2008 at 10:34 AM,  <rdmurray at bitdance.com> wrote:
> On Mon, 8 Dec 2008 at 13:16, Terry Reedy wrote:
>>>
>>>  And the decoding problems don't pass silently either - they just get
>>>  emitted as a warning by default instead of causing the application to
>>>  crash.
>>
>> Do they get automatically logged?  In any case, the errors parameter has
>> an in between option to neither ignore or raise but to replace and give
>> *something* printable.
>>
>> This situation seems like an ideal situation for a parameter which gives
>> the application program who uses Python a range of options to working with
>> an un-ideal world.  I am really flabbergasted why there is so much
>> opposition to doing so in favor of more difficult or less functional
>> alternatives.
>
> 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.

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!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list