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
Le choix de UTF-8 16 ou 32 pour la représentation interne est fait pour que tu n'utilises jamais un codage multi mot (le mot fait 8 bits en UTF-8, 16 bits en UTF-16 et 32 bits en UTF-32): la conversion en question est juste d'ajouter les bits nuls manquant à tes points unicode. Je ne parlerais pas vraiment de conversion mais plutôt de convention pour accéder à la mémoire. (Au niveau assembleur, tu fais xor eax, eax pour annuler eax, puis tu choisis de lire ton caractère de 8 16 ou 32 bits en faisant un mov vers ah, ax ou eax et puis c'est tout.)
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.
Je ne sais pas très bien ce que tu veux dire par «à la volée» mais cela me semble raisonnable qu'une fonction explicitement appelée déclenche un calcul.
[^] # Re: strings: Optimisation mémoire vs cpu?
Posté par Michaël (site web personnel) . En réponse à la dépêche Python 3.3 est sorti. Évalué à 2.
Le choix de UTF-8 16 ou 32 pour la représentation interne est fait pour que tu n'utilises jamais un codage multi mot (le mot fait 8 bits en UTF-8, 16 bits en UTF-16 et 32 bits en UTF-32): la conversion en question est juste d'ajouter les bits nuls manquant à tes points unicode. Je ne parlerais pas vraiment de conversion mais plutôt de convention pour accéder à la mémoire. (Au niveau assembleur, tu fais xor eax, eax pour annuler eax, puis tu choisis de lire ton caractère de 8 16 ou 32 bits en faisant un mov vers ah, ax ou eax et puis c'est tout.)
Je ne sais pas très bien ce que tu veux dire par «à la volée» mais cela me semble raisonnable qu'une fonction explicitement appelée déclenche un calcul.