Flexible string representation, unicode, typography, ...

[wxjmfauth at gmail.com]

Le mercredi 29 août 2012 14:01:57 UTC+2, Dave Angel a écrit :
> On 08/29/2012 07:40 AM, wxjmfauth at 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