On Fri, 11 Mar 2016 07:07 am, Chris Angelico wrote: > You _need_ [emphasis in original] to make sure > that you're thinking about text as text, and that means being aware of > RTL vs LTR, combining characters, case conversions, collations, etc, > etc, etc, all in terms of Unicode rather than as eight-bit or > seven-bit characters.
And I thought that I was a Unicode-evangelist... You don't "need" to do anything of the sort, any more than (say) Firefox needs to support displaying Scitex CT image files. If you want to put people off Unicode and make them even more resistant, the idea that there is no middle ground between "naive ASCII" and full, complete, total and utterly 100% coverage of the entire Unicode standard will do it nicely. Unicode covers a huge amount of ground, and most users won't need more than a fraction of it. Especially people like Bart, who are writing code for his own personal use. If Bart gets to the point of being able to correctly read and write his mostly ASCII text as UTF-8 files without moji-bake, that's probably more than he'll personally ever need. Or not. Only he will tell. > An intelligent Unicode-aware MUD client has to > not only cope with variable width That may be true, but that doesn't mean that there isn't still room in the world for dumb, just-barely Unicode capable clients. And frankly I would rather partial Unicode support than buggy Unicode support: I have a text editor which would be my preferred editor of choice except it has an annoying bug where it will (seemingly at random) switch to Right-To-Left mode for no reason, and then be impossible to switch back. Since I have *no* use for RTL, I would rather an editor that doesn't support that than one that supports it buggily. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
