On 28 mar, 07:12, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/27/2013 08:49 PM, rusi wrote: > > > In particular "You are a liar" is as bad as "You are an idiot" > > The same statement can be made non-abusively thus: "... is not true > > because ..." > > I don't agree. With all the posts and micro benchmarks and other drivel that > jmf has inflicted on us, I find it /very/ > hard to believe that he forgot -- which means he was deliberately lying. > > At some point we have to stop being gentle / polite / politically correct and > call a shovel a shovel... er, spade. > > -- > ~Ethan~
----------- The problem is elsewhere. Nobody understand the examples I gave on this list, because nobody understand Unicode. These examples are not random examples, they are well thought. If you were understanding the coding of the characters, Unicode and what this flexible representation does, it would not be a problem for you to create analog examples. So, we are turning into circles. This flexible representation succeeds to cumulate in one shoot all the design mistakes it is possible to do, when one wishes to implements Unicode. Example of a good Unicode understanding. If you wish 1) to preserve memory, 2) to cover the whole range of Unicode, 3) to keep maximum performance while preserving the good work Unicode.org as done (normalization, sorting), there is only one solution: utf-8. For this you have to understand, what is really a "unicode transformation format". Why all the actors, active in the "text field", like MicroSoft, Apple, Adobe, the unicode compliant TeX engines, the foundries, the "organisation" in charge of the OpenType font specifications, are able to handle all this stuff correctly (understanding + implementation) and Python not?, I should say this is going beyond my understanding. Python has certainly and definitvely not "revolutionize" Unicode. jmf -- http://mail.python.org/mailman/listinfo/python-list
