Le mercredi 29 août 2012 14:01:57 UTC+2, Dave Angel a écrit : > On 08/29/2012 07:40 AM, wxjmfa...@gmail.com wrote: > > > <snip> > > > > > Forget Python and all these benchmarks. The problem is on an other > > > level. Coding schemes, typography, usage of characters, ... For a > > > given coding scheme, all code points/characters are equivalent. > > > Expecting to handle a sub-range in a coding scheme without shaking > > > that coding scheme is impossible. If a coding scheme does not give > > > satisfaction, the only valid solution is to create a new coding > > > scheme, cp1252, mac-roman, EBCDIC, ... or the interesting "TeX" case, > > > where the "internal" coding depends on the fonts! Unicode (utf***), as > > > just one another coding scheme, does not escape to this rule. This > > > "Flexible String Representation" fails. Not only it is unable to stick > > > with a coding scheme, it is a mixing of coding schemes, the worst of > > > all possible implementations. jmf > > > > Nonsense. The discussion was not about an encoding scheme, but an > > internal representation. That representation does not change the > > programmer's interface in any way other than performance (cpu and memory > > usage). Most of the rest of your babble is unsupported opinion. >
I can hit the nail a little more. I have even a better idea and I'm serious. If "Python" has found a new way to cover the set of the Unicode characters, why not proposing it to the Unicode consortium? Unicode has already three schemes covering practically all cases: memory consumption, maximum flexibility and an intermediate solution. It would be to bad, to not share it. What do you think? ;-) jmf -- http://mail.python.org/mailman/listinfo/python-list
