On 28/03/13 09:03, jmfauth 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.
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.
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".
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.
jmf
You're confusing python's choice of internal string representation with
the programmer's choice of encoding for communicating with other programs.
I think most people agree that utf-8 is usually the best encoding to use
for interoperating with other unicode aware software, but as a
variable-length encoding it has disadvantages that make it unsuitable
for use as an internal representation.
Specifically, indexing a variable-length encoding like utf-8 is not as
efficient as indexing a fixed-length encoding.
Regards,
Ian F
--
http://mail.python.org/mailman/listinfo/python-list
