Et c'est quoi la raison fondamentale pour que ce ne soit pas possible de mélanger les bytes et l'unicode à l'écriture ?
La même raison pour laquelle on n'a pas le droit de concaténer bytes et unicode : parce que sémantiquement ça ne veut rien dire. Si vraiment tu veux le faire, tu dois gérer l'encodage à la main et ça te force à réfléchir à ce que tu fais : explicit is better than implicit.
Une autre raison plus pragmatique est que lors du portage d'un programme de Python 2.x à Python 3.x, il y a forcément des endroits où l'on passe des bytes par erreur plutôt que de l'unicode. Du coup, avoir une API standard relativement stricte vis-à-vis de cela permet de détecter les erreurs plus tôt.
(dans le cas de Mercurial, j'imagine que vous ferez presque tout en bytes de toute façon)
---
Note : la solution que je t'ai donnée est sous-optimale car elle recrée un objet fichier. On peut plus simplement faire :
>>> f = sys.stdout.buffer
>>> f
<io.BufferedWriter object at 0xb7c78fec>
>>> f.write(b"abc")
abc3
[^] # Re: Mercurial 2.0
Posté par Antoine . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 3.
La même raison pour laquelle on n'a pas le droit de concaténer bytes et unicode : parce que sémantiquement ça ne veut rien dire. Si vraiment tu veux le faire, tu dois gérer l'encodage à la main et ça te force à réfléchir à ce que tu fais : explicit is better than implicit.
Une autre raison plus pragmatique est que lors du portage d'un programme de Python 2.x à Python 3.x, il y a forcément des endroits où l'on passe des bytes par erreur plutôt que de l'unicode. Du coup, avoir une API standard relativement stricte vis-à-vis de cela permet de détecter les erreurs plus tôt.
(dans le cas de Mercurial, j'imagine que vous ferez presque tout en bytes de toute façon)
---
Note : la solution que je t'ai donnée est sous-optimale car elle recrée un objet fichier. On peut plus simplement faire :
>>> f = sys.stdout.buffer
>>> f
<io.BufferedWriter object at 0xb7c78fec>
>>> f.write(b"abc")
abc3