Flexible string representation, unicode, typography, ...

[Dave Angel]

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.

Plonk.



-- 

DaveA