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 | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org