On 06/04/2014 12:50 AM, wxjmfa...@gmail.com wrote:
> Like many, you are not understanding unicode because
> you do not understand the coding of characters.
If that is true, then I'm sure a well-written paragraph or two can set
him straight. You continually berate people for not understanding
unicode, but you've posted nothing to explain anything, nor demonstrate
your own understanding. That's one reason your posts are so frustrating
and considered trolling. You never ever explain yourself, instead just
flailing around and muttering about folks not understanding unicode,
just as you've done here, true to form.
> You do not understand the coding of the characters
> because you do not understand the mathematics behind it.
flamebaiting here... FSR *is* UTF-32 internally, compresses off leading
zero bits during string creation.
> You focussed on the wrong problem.
Frankly it is you who is focused on the wrong problem, at least with
this particular thread. I think you got distracted by the subject line.
Chris's original post really has nothing to do with unicode at all.
He's simply asking for use cases for string indexing where O(1) is
desired or necessary. Could be old Python 2 byte strings, or Python 3
unicode strings. It does not matter. Unicode is orthogonal to his
Maybe his purpose in asking the question is to justify a fixed-length
encoding scheme (which is what FSR actually is), or maybe it is to
explore the costs of using a much slower, but more compact,
variable-length encoding scheme like UTF-8. Particularly in the context
of low-memory applications where unicode support would be nice, but
memory is at a premium. But either way, you got hung up on the wrong thing.
> (All this stuff has been discussed, tested and worked on
> 20 (twenty) years ago.)
As am I.