On Thu, Dec 4, 2008 at 10:14 PM, Guido van Rossum <guido at python.org> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4