D'après la PEP-393 il y a bien plusieurs représentations possibles de la string en interne.
Cependant ça concerne uniquement la représentation unicode. La PEP parle d'ascii car c'est un sous ensemble de l'UTF-8: toute chaîne de caractère ascii peut être lue comme une chaîne UTF-8.
Il y a donc bien une conversion à la volée des caractères entre l'encodage interne qui peut être de l'UTF-8, UTF-16 ou UTF-32, et la représentation publique, au moins dans les cas où on accède aux caractères directement (ils sont convertis en code-point unicode). Cela dit cette conversion était aussi faite avant.
Pour la concaténation effectivement je ne sais pas si c'est réellement un problème.
Cependant dans la PEP ils précisent:
> A new function PyUnicode_AsUTF8 is provided to access the UTF-8 representation. It is thus identical to the existing _PyUnicode_AsString, which is removed. The function will compute the utf8 representation when first called. Since this representation will consume memory until the string object is released, applications should use the existing PyUnicode_AsUTF8String where possible (which generates a new string object every time). APIs that implicitly converts a string to a char* (such as the ParseTuple functions) will use PyUnicode_AsUTF8 to compute a conversion.
Ce qui veut bien dire qu'il y a des méthodes utilisées qui font de la conversion à la volée.
Cf aussi la liste des fonctions et macros de leur nouvelle API.
[^] # Re: strings: Optimisation mémoire vs cpu?
Posté par NilugeKiWi . En réponse à la dépêche Python 3.3 est sorti. Évalué à 2.
D'après la PEP-393 il y a bien plusieurs représentations possibles de la string en interne.
Cependant ça concerne uniquement la représentation unicode. La PEP parle d'ascii car c'est un sous ensemble de l'UTF-8: toute chaîne de caractère ascii peut être lue comme une chaîne UTF-8.
Il y a donc bien une conversion à la volée des caractères entre l'encodage interne qui peut être de l'UTF-8, UTF-16 ou UTF-32, et la représentation publique, au moins dans les cas où on accède aux caractères directement (ils sont convertis en code-point unicode). Cela dit cette conversion était aussi faite avant.
Pour la concaténation effectivement je ne sais pas si c'est réellement un problème.
Cependant dans la PEP ils précisent:
> A new function PyUnicode_AsUTF8 is provided to access the UTF-8 representation. It is thus identical to the existing _PyUnicode_AsString, which is removed. The function will compute the utf8 representation when first called. Since this representation will consume memory until the string object is released, applications should use the existing PyUnicode_AsUTF8String where possible (which generates a new string object every time). APIs that implicitly converts a string to a char* (such as the ParseTuple functions) will use PyUnicode_AsUTF8 to compute a conversion.
Ce qui veut bien dire qu'il y a des méthodes utilisées qui font de la conversion à la volée.
Cf aussi la liste des fonctions et macros de leur nouvelle API.