Guido van Rossum wrote:
> The callback would either be an extra argument to all
> system calls (bad, ugly etc., and why not go with the existing unicode
> encoding and error flags if we're adding extra args?) or would be
> global, where I'd be worried that it might interfere with the proper
> operation of library code that is several abstractions away from
> whoever installed the callback, not under their control, and not
> expecting the callback.
>
> I suppose I may have totally misunderstood your proposal, but in
> general I find callbacks unwieldy.
Not really - later in the email, I actually pointed out that exposing
the unicode errors flag for the implicit PyUnicode_Decode invocations
would be enough to enable a callback mechanism.
However, James's post pointing out that this is a problem that also
affects environment variables and command line arguments, not just file
paths completely kills any hope of purely callback based approach - that
processing needs to "just work" without any additional intervention from
the application.
Of the suggestions I've seen so far, I like Marcin's Mono-inspired
NULL-escape codec idea the best. Since these strings all come from parts
of the environment where NULLs are not permitted, a simple "'\0' in
text" check will immediately identify any strings where decoding failed
(for applications which care about the difference and want to try to do
better), while applications which don't care will receive perfectly
valid Python strings that can be passed around and manipulated as if the
decoding error never happened.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
