Glenn Linderman writes: > OK, but file names are not (always) Unicode strings. So it is possible > to have a conforming process that still manipulates non-Unicode > filenames, as long as it doesn't emit them in places where Unicode > strings are required.
Sure. My point is that "emission elimination" is very hard to arrange under any of the not-quite Unicode schemes that have been discussed, and almost surely the effort to achieve even "emission reduction" will almost never occur if we default to imperfect but pretty good sanitization. It will encourage the same kind of coding that we're familiar with already: things almost always work for most programmers if they assume that it's OK to ignore the problem. > So when a foreign file system is mounted, the driver for that file > system gets "first crack" and defining legal names and how to > handle files that don't have legal names. For example, on Windows, > I wouldn't be surprised to see NFS drivers that suppress > non-Unicode names at the 16-bit API level. At that point, Python > would not be responsible for ... much of anything. Nice work if we can get it; I won't be holding my breath. For starters, USB memory sticks are still all FAT format by default. > There are lots of kinds of strings. Not in Python, though. There are Unicode strings and there are bytes objects. If the latter were acceptable for this application, we'd have no problem. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
