At 07:16 PM 10/29/2001 -0500, James Mastros wrote: >Yeah. But that's a convention thing, I think. I also think that most >people won't go to the bother of writing conversion functions that they >don't have to. What we need to worry about is both, say, big5 and shiftjis >writing both of the conversions. And it shouldn't come up all that much, >because Unicode is /supposted to be/ lossless for most things.
Supposed to be, yep. Whether it *is* or not is another issue entirely. :) > > I suspect that the encode and decode methods in the encoding vtable > > are enough for doing chr/ord aren't they? >Hmm... come to think of it, yes. chr will always create a utf32-encoded >string with the given charset number (or unicode for the two-arg version), >ord will return the codepoint within the current charset. Erk. No. chr should give you a string in the encoding you've selected, or the default encoding if you've not selected one. That may not be (probably won't be) UTF32. >(This, BTW, means that only encodings that feel like it have to provide >either, but all encodings must be able to convert to utf32.) More or less, yep. Everyone has to go to UTF32. Direct encoding to encoding is optional. Encouraged in those cases where it's either quicker or less uncertain. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk