Dangers du sys.setdefaultencoding('utf-8')

L'affiche originale a demandé de code qui montre que l'interrupteur est dangereux—sauf qu'il "cache" bugs sans rapport avec le commutateur.

Résumé des conclusions

Basé à la fois sur l'expérience et des données que j'ai recueillies, voici les conclusions auxquelles je suis arrivé au.

1. Réglage de la defaultencoding de l'UTF-8 de nos jours est sûr, sauf pour des applications spécialisées, manipulation de fichiers non unicode prêt systèmes.

2. "Officiel" rejet de l'interrupteur est basé sur des raisons qui ne sont plus pertinentes pour une grande majorité d'utilisateurs (pas de bibliothèque fournisseurs), de sorte que nous devrions cesser de décourager les utilisateurs à définir.

3. De travail dans un modèle qui gère l'Unicode correctement par défaut est de loin mieux adapté pour les applications de la inter-systèmes de communications que manuellement travailler avec unicode Api.

Effectivement, la modification de l'encodage par défaut très fréquemment évite un certain nombre de l'utilisateur maux de tête dans la grande majorité des cas d'utilisation. Oui, il existe des situations dans lesquelles les programmes d'encodages multiples silencieusement se conduisent mal, mais depuis ce commutateur peut être activé de façon fragmentaire, c'est pas un problème dans le code de l'utilisateur.

Plus important encore, l'activation de ce drapeau est un réel avantage est des utilisateurs de code, à la fois par la réduction de la surcharge d'avoir à gérer manuellement conversions Unicode, encombrer le code et de le rendre moins lisible, mais aussi en évitant les éventuels bugs lorsque le programmeur ne parvient pas à le faire correctement dans tous les cas.

---

Étant donné que ces revendications sont à peu près l'exact opposé de Python ligne officielle de la communication, je pense que l'une des explications de ces conclusions est justifiée.

Exemples de succès en utilisant une version modifiée de defaultencoding dans la nature

1. Dave Malcom de Fedora pense que c'est toujours droit. Il a proposé, après avoir enquêté sur les risques, l'évolution de la distribution à l'échelle def.enc.=UTF-8 pour tous les utilisateurs de Fedora.

   Dur fait présenté si pourquoi Python serait pause n'est que le hachage de comportement je répertorié, qui n'est jamais repris par tout autre adversaire dans le noyau de la communauté, comme une raison de s'inquiéter ou même par le même personne, lorsque l'on travaille sur de l'utilisateur de billets.

   Résumé de Fedora: Certes, le changement lui-même a été décrit comme "follement impopulaire" avec les développeurs, et il a été accusé d'être incompatible avec les versions précédentes.

2. Il y a 3000 de projets à l'openhub de le faire. Ils ont une recherche lente frontend, mais la numérisation sur elle, j'estime à 98% l'utilisation de l'UTF-8. Rien trouvé sur de mauvaises surprises.

3. Il y a 18000(!) github maître branches avec elle changé.

   Alors que le changement est "impopulaire" au cœur de la communauté assez populaires dans la base des utilisateurs. Bien que cela puisse être écartée, puisque les utilisateurs sont connus pour utiliser des hacky solutions, je ne pense pas que c'est un argument pertinent en raison de mon prochain point.

4. Il y a seulement 150 bugreports total sur GitHub à cause de cela. À un taux de manière efficace à 100%, le changement semble être positive, et non négative.

   Pour résumer les problèmes existants personnes ont courir dans les, j'ai scanné par le biais de toutes ces billets.

   • Chaging def.enc. UTF-8 est généralement introduit mais pas supprimé la question d'un processus de clôture, le plus souvent comme une solution. Certains plus grands excuser comme correctif temporaire, compte tenu de la "mauvaise presse" il a, mais beaucoup plus de bug, les journalistes justeheureux sur le correctif.

   • Un peu (1 à 5?) les projets de modification de leur code à faire les conversions de type manuellement de sorte qu'ils n'ont pas besoin de changer la valeur par défaut plus.

   • Dans les deux cas je vois quelqu'un qui prétend qu'avec def.enc. ensemble de l'UTF-8 conduit à une absence totale de sortie entièrement, sans en expliquer la configuration de test. Je ne pouvais pas vérifier cette affirmation, et j'ai testé un et a trouvé le contraire pour être vrai.

   • Un les réclamations son "système" peut dépendre de ne pas changer, mais nous n'apprenons pas pourquoi.

   • (Et seulement) avait une vraie raison pour l'éviter: ipython utilise soit un 3ème partie module ou le test runner modifié leurs processus de manière incontrôlée (il n'est jamais contesté que le def.enc. le changement est préconisé par son promoteurs seulement à l'interprète de temps d'installation, c'est à dire lorsque les "posséder" le processus).

5. J'ai trouvé l'indication zéro que les différentes valeurs de hachage de 'é' et u é' provoque des problèmes dans le monde réel code.

6. Python n' pas "pause"

   Après avoir modifié le réglage de l'UTF-8, pas de fonctionnalité de Python couverts par les tests unitaires est de travailler différemment, sans le commutateur. Le commutateur lui-même, cependant, n'est pas testé du tout.

7. Il est conseillé sur les bugs.python.org aux frustrations des utilisateurs

   Exemples ici, ici ou ici
   (souvent en rapport avec la ligne officielle de l'avertissement)

   Le premier montre comment établi que l'interrupteur est en Asie (comparer aussi avec le github de l'argumentation).

8. Ian Bicking publié son soutien pour toujours l'activation de ce comportement.

   Je peux faire mes systèmes et des communications de façon constante UTF-8, les choses vont juste aller mieux. Je ne vois vraiment pas un inconvénient. Mais pourquoi Python assurez-il SI SACRÉMENT DUR [...] j'ai l'impression que quelqu'un a décidé qu'ils étaient plus intelligents que moi, mais je ne suis pas sûr que je le crois.

9. Martijn Fassen, tout en réfutant Ian, admis que ASCII pourrait avoir été mal dans la première place.

   Je crois que si, par exemple, Python 2.5, livré par défaut avec un encodage UTF-8, il ne serait pas casser quoi que ce soit. Mais si je l'ai fait pour mon Python, j'aurais des problèmes dès que j'ai donné mon code à quelqu'un d'autre.

10. En Python3, ils ne sont pas en pratique ce qu'ils prêchent"

    Tout en s'opposant à toute définition.enc. changement si durement en raison de l'environnement code dépendant désire, une discussion ici tourne Python3's des problèmes avec ses "unicode sandwich" paradigme et le correspondant tenu des hypothèses implicites.

    En outre, ils ont créé des possibilités pour écrire valide Python3-code comme:

    >>> from 褐褑褒褓褔褕褖褗褘 import *        
    >>> def 空手(合氣道): あいき(ど(合氣道))
    >>> 空手(う힑힜(' ') + 흾)
    

11. DiveIntoPython le recommande.

12. Dans ce fil, Guido lui-même conseille un professionnel de l'utilisateur final utiliser un processus spécifique environt avec le commutateur à "créer un environnement Python pour chaque projet."

    La raison fondamentale pour laquelle les designers de Python 2.x de la bibliothèque standard ne veux pas que vous soyez en mesure de définir l'encodage par défaut de votre application, c'est que la bibliothèque standard est écrit avec l'hypothèse que l'encodage par défaut est fixe, et aucune garantie quant au bon fonctionnement de la bibliothèque standard peut être fait quand vous le changez. Il n'y a pas de tests pour cette situation. Personne ne sait ce qui va échouer lorsque. Et vous (ou pire, de vos utilisateurs) vont venir nous voir avec des plaintes si le standard de la bibliothèque se met soudain à faire des choses que vous n'attendiez pas.

13. Jython propose de le changer à la volée, même dans des modules.

14. PyPy a pas support de rechargement(sys) - mais il ramena sur la demande de l'utilisateur au sein d'un seul jour sans se poser de questions. Comparer avec la "vous le faites mal" attitude de Disponible, revendiquant sans preuve c'est la "racine du mal".

---

Fin de cette liste, je confirme que l'on pourrait construire un module qui se bloque parce que de changement d'interprète de config, de faire quelque chose comme ceci:

def is_clean_ascii(s):
    """ [Stupid] type agnostic checker if only ASCII chars are contained in s"""
    try:
        unicode(str(s))
        # we end here also for NON ascii if the def.enc. was changed
        return True
    except Exception, ex:
        return False    

if is_clean_ascii(mystr):
    <code relying on mystr to be ASCII>

Je ne pense pas que ce soit un argument valable, car la personne qui a écrit ce double type d'accepter module était évidemment au courant au sujet de l'ASCII et non des chaînes ASCII et serait au courant de l'encodage et du décodage.

Je pense que cette preuve est plus d'une indication suffisante que la modification de ce paramètre ne conduisent pas à des problèmes dans le monde réel des bases de codes la vaste majorité du temps.

Tout d'abord: de Nombreux adversaires de l'évolution de défaut enc faire valoir que son stupide, parce que son même en changeant ascii comparaisons

Je pense que c'est juste pour faire comprendre que, conformes à la question d'origine, je vois que personne ne préconisent rien d'autre que de s'écartant de l'Ascii vers UTF-8.

La setdefaultencoding('utf-16') exemple semble être toujours mis en avant par ceux qui s'opposent à changer 😉

---

Avec m = {'a': 1, 'é': 2} et le fichier 'out.py':

# coding: utf-8
print u'é' 

Alors:

+---------------+-----------------------+-----------------+
| DEF.ENC       | OPERATION             | RESULT (printed)|            
+---------------+-----------------------+-----------------+
| ANY           | u'abc' == 'abc'       | True            |     
| (i.e.Ascii    | str(u'abc')           | 'abc'           |
|  or UTF-8)    | '%s %s' % ('a', u'a') | u'a a'          | 
|               | python out.py         | é               |
|               | u'a' in m             | True            |
|               | len(u'a'), len(a)     | (1, 1)          |
|               | len(u'é'), len('é')   | (1, 2) [*]      |
|               | u'é' in m             | False  (!)      |
+---------------+-----------------------+-----------------+
| UTF-8         | u'abé' == 'abé'       | True   [*]      |
|               | str(u'é')             | 'é'             |
|               | '%s %s' % ('é', u'é') | u'é é'          | 
|               | python out.py | more  | 'é'             |
+---------------+-----------------------+-----------------+
| Ascii         | u'abé' == 'abé'       | False, Warning  |
|               | str(u'é')             | Encoding Crash  |
|               | '%s %s' % ('é', u'é') | Decoding Crash  |
|               | python out.py | more  | Encoding Crash  |
+---------------+-----------------------+-----------------+

[*]: Résultat suppose la même é. Voir ci-dessous sur ce.

En regardant ces opérations, la modification de l'encodage par défaut dans votre programme ne pourrait pas l'air trop mauvais, vous donnant des résultats "plus proche" d'avoir Ascii uniquement des données.

Concernant le hachage () et len() le comportement que vous obtenez la même chose, alors en Ascii (en savoir plus sur les résultats ci-dessous). Ces opérations montrent également qu'il existe d'importantes différences entre unicode et les chaînes d'octets qui pourrait provoquer des erreurs logiques, s'il est ignoré par vous.

Comme on l'a déjà vu: C'est un processus à l'échelle option si vous avez juste un coup de choisir ce qui est la raison pour laquelle bibliothèque les développeurs devraient vraiment de ne plus jamais le faire, mais obtenir leurs internes afin de sorte qu'ils n'ont pas besoin de compter sur python conversions implicites.
Ils ont également besoin de documenter clairement ce qu'ils attendent et de retour et de refuser l'entrée qu'ils n'ont pas écrit la lib (comme la fonction normaliser, voir ci-dessous).

=> Écrire des programmes avec ce paramètre sur fait-il risqué pour les autres à utiliser les modules de votre programme dans leur code, au moins sans filtrage d'entrée.

Remarque: Certains opposants affirment que le def.enc. c'est même un système à l'échelle de l'option (via sitecustomize.py), mais plus tard dans les moments de logiciels de la conteneurisation (menu fixe) chaque processus peut être commencé dans un environnement idéal w/o frais généraux.

---

Concernant le hachage et len() comportement:

Il vous dit que même une modification de la def.enc. vous ne pouvez pas toujours être ignorant sur les types de chaînes que vous traitez dans votre programme. u" et " sont différentes séquences d'octets dans la mémoire - pas toujours, mais en général.

Donc lors de l'essai assurez-vous que votre programme fonctionne correctement aussi avec les données Ascii.

Certains disent que le fait que les hachages peut devenir inégale lorsque les données de la modification des valeurs - bien qu'en raison de conversions implicites le '==' activités demeurent égaux - est un argument contre un changement de def.enc.

Personnellement, je ne partage pas que, depuis le hachage le comportement reste le même que w/o de le changer. Encore un exemple convaincant de comportements indésirables en raison de ce paramètre dans un processus de I 'propre'.

Dans l'ensemble, concernant setdefaultencoding("utf-8"): La réponse quant à si le son muet ou pas devrait être plus équilibré.

Il dépend.
Alors que c'est à éviter les collisions par exemple, à la str() opérations dans un journal de l'instruction, le prix est une chance plus élevée pour des résultats inattendus, plus tard, puisque le mauvais types en faire plus dans le code, dont le bon fonctionnement dépend d'un certain type.

En aucun cas, il devrait être l'alternative à l'apprentissage de la différence entre les chaînes d'octets et des chaînes unicode pour votre propre code.

---

Enfin, le paramètre de codage par défaut, loin de l'Ascii ne permet pas de rendre votre vie plus facile pour la commune de texte opérations comme len(), de tranchage et de comparaisons - devrait-on supposer que (byte)stringyfying le tout avec de l'UTF-8 sur résout les problèmes ici.

Malheureusement il n'a pas - en général.

Le '==' et len() les résultats sont loin problème plus complexe qu'on pourrait le penser - mais même avec la même type sur les deux côtés.

W/o def.enc. changé "==" ne parvient pas toujours à des fins non Ascii, comme indiqué dans le tableau. Avec elle, il fonctionne, parfois:

Unicode ne s'uniformiser autour d'un million de symboles du monde et leur a donné un certain nombre - mais il n'est malheureusement PAS un rapport de 1:1 bijection entre les glyphes affiché à l'utilisateur dans les périphériques de sortie et les symboles qu'ils sont générés à partir de.

Pour vous motiver la recherche de cette: le fait d'Avoir deux fichiers, j1, j2, écrit avec la même programme en utilisant le même encodage, contenant la saisie de l'utilisateur:

>>> u1, u2 = open('j1').read(), open('j2').read()
>>> print sys.version.split()[0], u1, u2, u1 == u2

Résultat: 2.7.9 José José Faux (!)

À l'aide de l'impression en fonction de Py2 vous voyez la raison: Malheureusement, il y a DEUX façons de coder le même caractère, les caractères accentués 'e':

>>> print (sys.version.split()[0], u1, u2, u1 == u2)
('2.7.9', 'Jos\xc3\xa9', 'Jose\xcc\x81', False)

Ce qu'un stupide codec direz-vous mais ce n'est pas la faute de la codec. C'est un problème dans unicode en tant que tel.

De sorte que même dans Py3:

>>> u1, u2 = open('j1').read(), open('j2').read()
>>> print sys.version.split()[0], u1, u2, u1 == u2

Résultat: 3.4.2 José José Faux (!)

=> Indépendant de Py2 et Py3, réellement indépendant de tout langage de calcul que vous utilisez Pour écrire un logiciel de qualité, vous avez probablement de "normaliser" toutes les entrées utilisateur. Le standard unicode ne standardiser la normalisation.
En Python 2 et 3 de la unicodedata.normaliser la fonction est votre ami.

Une chose que nous devons savoir est

Python 2 utilisez sys.getdefaultencoding() pour décoder/encoder entre str et unicode

donc, si nous changeons de codage par défaut, il y aura toutes sortes de questions incompatibles. par exemple:

# coding: utf-8
import sys
print "你好" == u"你好"
# False
reload(sys)
sys.setdefaultencoding("utf-8")
print "你好" == u"你好"
# True

Plus d'exemples:

• https://pythonhosted.org/kitchen/unicode-frustrations.html

Cela dit, je me souviens il y a quelques blog ce qui suggère l'utilisation de l'unicode chaque fois que possible, et la seule chaîne de bits lors de l'affaire I/O. je pense que si votre suivi de cette convention, la vie sera beaucoup plus facile. Plusieurs solutions peuvent être trouvées:

• https://pythonhosted.org/kitchen/unicode-frustrations.html#a-few-solutions