On 28 March 2013 09:03, jmfauth <wxjmfa...@gmail.com> wrote: > > 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.
There are many people here and among the Python devs who understand unicode. Similarly they have understood the examples that you have given. It has been accepted that there are a handful of cases where performance has been reduced as a result of the change. There are also many cases where the performance has improved. It is certainly not clear that there is an *overall* performance reduction for people using non latin-1 characters as you have often suggested. The reason your initial posts received a poor reception is that they were accompanied with pointless rants and arrogant claims that no one understood the problem. Had you simply reported the timing differences without the rants then I imagine that you would have received a response like "Okay, there might be a few regressions. Can you open an issue on the tracker please?". Since then you have been relentlessly hijacking unrelated threads and this is clearly just trolling. > > 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. This is clearly untrue.The most significant design mistakes are the ones that lead to incorrect handling of unicode characters. This new implementation in Python 3.3 has been designed in a way that makes it possible to handle all unicode characters correctly. > > 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". Again you pretend that others here don't understand. Most people here are well aware of utf-8 is. Your suggestion that "maximum performance" would be achieved if Python use utf-8 internally ignores the fact that it would have many negative performance implications for slicing and indexing and so on. > > 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. Perhaps not, but it does now correctly handle all unicode characters (unlike many other languages and pieces of software). Oscar -- http://mail.python.org/mailman/listinfo/python-list
