Non c'est un vrai problème (qui est en discussion sur python-devel et qui selon moi est fondamental).
Effectivement, ce point épineux a provoqué des discussions assez houleuses sur la liste de diffusion. Il y a trois choses : sys.argv, noms des fichiers, et les variables d'environnement. Pour l'instant, tout est accessible en Unicode.
Pour les fichiers, j'ai écrit un patch pour pouvoir utiliser des noms de fichier sous forme d'octets. Ce travail a pris plusieurs mois mais a été intégré pour la sortie de la version 3.0 finale.
Pour les variables d'environnement (comme PATH), c'est en cours de discussion. Je pense que la version 3.1 pourra accéder aux variables d'environnement en tant qu'octets. Pour sys.argv, personne ne s'en est plaint (pas de bug ouvert, je crois) :-) Sûrement qu'à terme, il existera aussi une méthode pour accéder à la version en octets.
La solution que je déteste et que plusieurs personnes essayent à chaque fois de pousser, est de stocker des octets dans Unicode en utilisant un encodage spécial (ex: utiliser une plage réservée d'Unicode). Mais je ne comprend pas l'intérêt car on revient au status pourri de Python2 qui mélange octets et caractères, source de nombreux bugs. En particulier, le texte Unicode n'est plus interopérable :-/
À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.
Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !
[^] # Re: Tout les bugs ? vraiment ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 3.
Effectivement, ce point épineux a provoqué des discussions assez houleuses sur la liste de diffusion. Il y a trois choses : sys.argv, noms des fichiers, et les variables d'environnement. Pour l'instant, tout est accessible en Unicode.
Pour les fichiers, j'ai écrit un patch pour pouvoir utiliser des noms de fichier sous forme d'octets. Ce travail a pris plusieurs mois mais a été intégré pour la sortie de la version 3.0 finale.
Pour les variables d'environnement (comme PATH), c'est en cours de discussion. Je pense que la version 3.1 pourra accéder aux variables d'environnement en tant qu'octets. Pour sys.argv, personne ne s'en est plaint (pas de bug ouvert, je crois) :-) Sûrement qu'à terme, il existera aussi une méthode pour accéder à la version en octets.
La solution que je déteste et que plusieurs personnes essayent à chaque fois de pousser, est de stocker des octets dans Unicode en utilisant un encodage spécial (ex: utiliser une plage réservée d'Unicode). Mais je ne comprend pas l'intérêt car on revient au status pourri de Python2 qui mélange octets et caractères, source de nombreux bugs. En particulier, le texte Unicode n'est plus interopérable :-/
À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.
Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !