C'est comme pour les outils de backup, si un nom fichier n'est pas décodable depuis la locale utilisée vers unicode, on ne peut pas l'ignorer non plus, donc on considère les noms de fichiers comme des bytes.
Par exemple, si les noms de fichiers sont en UTF-8, mais que pour une raison ou pour une autre (par exemple ton programme est lancé depuis cron), mercurial est lancé avec la locale "C", alors si on considérait les noms de fichiers comme autre chose que des bytes, alors ça planterait (on ne peut pas ouvrir certains fichiers par exemple).
Maintenant le problème pour nous en dehors de transformer tous les open/listdir/etc en version bytes (bon a priori on est déjà en binary mode à cause de windows donc les open ça doit être bon) c'est que l'API bytes n'est pas complete, par exemple au niveau de sys.argv et os.environ.
Et à mon avis il y encore d'autres problèmes qui n'ont pas été résolus par exemple je n'ai aucune idée de comment on peut écrire des bytes dans sys.stdout.
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 1.
Par exemple, si les noms de fichiers sont en UTF-8, mais que pour une raison ou pour une autre (par exemple ton programme est lancé depuis cron), mercurial est lancé avec la locale "C", alors si on considérait les noms de fichiers comme autre chose que des bytes, alors ça planterait (on ne peut pas ouvrir certains fichiers par exemple).
Maintenant le problème pour nous en dehors de transformer tous les open/listdir/etc en version bytes (bon a priori on est déjà en binary mode à cause de windows donc les open ça doit être bon) c'est que l'API bytes n'est pas complete, par exemple au niveau de sys.argv et os.environ.
Et à mon avis il y encore d'autres problèmes qui n'ont pas été résolus par exemple je n'ai aucune idée de comment on peut écrire des bytes dans sys.stdout.