On Thu, Dec 4, 2008 at 10:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > At the risk of bringing up something that was already rejected, let me > propose something that follows the path taken in 3.0 for filenames, > rather than doubling back: > > For os.environ, os.getenv() and os.putenv(), I think a similar > approach as used for os.listdir() and os.getcwd() makes sense: let > os.environ skip variables whose name or value is undecodable, and have > a separate os.environb() which contains bytes; let os.getenv() and > os.putenv() do the right thing when the arguments passed in are bytes.
+1 (as that's what I suggested) > For sys.argv, because it's positional, you can't skip undecodable > values, so I propose to use error=replace for the decoding; again, we > can add sys.argvb that contains the raw bytes values. The various > os.exec*() and os.spawn*() calls (as well as os.system(), os.popen() > and the subprocess module) should all accept bytes as well as strings. +1. I wish there was a better solution to sys.argv. > On Windows, the bytes APIs should probably not exist. -0. I'd prefer byte APIs return UTF-16 bytes and the unicode APIs become validating. > I predict that most developers can get away with not using the bytes > APIs at all. The small minority that needs to be robust if not all > filenames use the system encoding can use the bytes APIs. This would > be developers on various Unix systems except OSX (which uses UTF8 for > its filesystems), and perhaps the occasional developer on OSX whose > app needs to work with files on mounted filesystems that use a > different encoding. -- Adam Olsen, aka Rhamphoryncus _______________________________________________ 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
