Guido van Rossum writes: > This sounds too pessimistic to me. I expect that in five years it will > be universally accepted that these variables must be encoded in a > standard encoding.
Archival material will not catch up until the plastic rots. And I bet it takes ten years before the Japanese accept the same standard encoding as the rest of the world (the Japanese cellphone system and iMode still speak Shift JIS). Five years should be plenty of time, but big Japanese companies are very sensitive (and resistant to) anything that might tend to open their turf to invaders. > People are never going to give up thinking about filenames etc. as > strings, because that's what they are conceptually. People can't win this one 100%, they have to choose between convenience with occasional fatal errors, or reliability. Python should not make it hard to achieve either. The default should be convenience, of course, but there should be a layer where "decodable per standard" values and "not decoded" values are different types. This is why Martin's proposal (or any other proposal to use strings with invalid values) is nearly unacceptable, really. What those who want reliability would have to do is to immediately decode all strings from the system into something like what Toshio proposes. This would be a lot more reliable if done by Python rather than an explicitly imported library, though, and would be available for debugging of cases where the default "values are text" representation falls down. The same "text on the surface, bytes in the background" type could be used by the email module (which already implements something like this). > The problem is purely one of encoding, No, it's not. It's that strings (as understood by people) and system "text" are different types (even on Mac: VFAT and NFS filesystem filenames for example), and Python is not type-safe in this sense. There ought to be a "you think this is text but I'm keeping an accurate backup just in case" type for this. _______________________________________________ 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
