Op 31-07-13 10:32, wxjmfa...@gmail.com schreef:
> Unicode/utf*
> ============
>
> i) ("primary key") Create and use a unique set of encoded
> code points.
FSR does this.
>>> st1 = 'a€'
>>> st2 = 'aa'
>>> ord(st1[0])
97
>>> ord(st2[0])
97
>>>
> ii) ("secondary key") Depending of the wish,
> memory/performance: utf-8/16/32
Whose wish? I don't know any language that allows the
programmer choose the internal representation of its
strings. If it is the designers choice FSR does this,
if it is the programmers choice, I don't see why
this is necessary for compliance.
> Two advantages at the light of the above example:
> iii) The "a" has never to be reencoded.
FSR: check. Using a container with wider slots is not a reëncoding.
If such widening is encoding then your 'choice' between utf-8/16/32
implies that it will also have to reencode when it changes from
utf-8 to utf-16 or utf-32.
> iv) An "a" size never exceeds 4 bytes.
FSR: check.
> Hard job to solve/satisfy i), ii), iii) and iv) at the same time.
> Is is possible? ;-) The solution is in the problem.
Mayby you should use bytes or bytearrays if that is really what you want.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
