RE Module Performance

[Antoon Pardon]

Op 31-07-13 10:32, wxjmfauth at 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