Bonne façon de définir le codage du code source Python

163

PEP 263 définit comment déclarer le codage du code source Python.

Normalement, les 2 premières lignes d'un fichier Python devraient commencer par:

#!/usr/bin/python
# -*- coding: <encoding name> -*-

Mais j'ai vu beaucoup de fichiers commençant par:

#!/usr/bin/python
# -*- encoding: <encoding name> -*-

=> encodage au lieu de codage .

Alors, quelle est la bonne façon de déclarer le codage du fichier?

L' encodage est-il autorisé parce que l'expression régulière utilisée est paresseuse? Ou est-ce juste une autre forme de déclaration du codage du fichier?

Je pose cette question parce que le PEP ne parle pas d' encodage , il parle simplement de codage .

python encoding

— Oli
source

4

À propos, pour plus de flexibilité et de portabilité, il est recommandé d'utiliser à la #!/usr/bin/env pythonplace de#!/usr/bin/python

— glarrain

7

J'aime la façon dont aucune des réponses sur cette page n'a d'exemple simple et fonctionnel, par exemple UTF8. StackOverly à son meilleur.

— aaa90210

2

Je voulais juste ajouter que Python 3 a changé le codage par défaut de asciià UTF-8. Comparez: les documents python 2.7 avec les documents python 3.7 . Cela signifie que vous pouvez en toute sécurité omettre cet encodage si vous souhaitez le spécifier UTF-8.

— gertvdijk

161

Consultez les documents ici :

"Si un commentaire dans la première ou la deuxième ligne du script Python correspond à l'expression régulière coding[=:]\s*([-\w.]+), ce commentaire est traité comme une déclaration d'encodage"

"Les formes recommandées de cette expression sont

# -*- coding: <encoding-name> -*-

qui est également reconnu par GNU Emacs, et

# vim:fileencoding=<encoding-name>

qui est reconnu par le VIM de Bram Moolenaar. "

Donc, vous pouvez mettre à peu près n'importe quoi avant la partie "codage", mais vous en tenir au "codage" (sans préfixe) si vous voulez être 100% compatible avec python-docs-recommandation.

Plus précisément, vous devez utiliser tout ce qui est reconnu par Python et le logiciel d'édition spécifique que vous utilisez (s'il a besoin / accepte quoi que ce soit). Par exemple, la codingforme est reconnue (prête à l'emploi) par GNU Emacs mais pas par Vim (oui, sans accord universel, c'est essentiellement une guerre de territoire ).

— Rafał Dowgird
source

11

Pourquoi le -*-?

— Iulian Onofrei

10

Le -*-garantit que la ligne est reconnue par GNU Emacs (un éditeur de texte populaire auprès de certains programmeurs). Notez que, contrairement à cette réponse, le formulaire Emacs et le formulaire Vim sont 100% compatibles avec python-docs-recommandation (car ils correspondent tous les deux à l'expression rationnelle - "match", par convention de longue date, signifie "match n'importe où dans le string ", contrairement à l'API de Python).

— martinjs

1

Les exigences Emacs spécifiques aux directives intégrées sont documentées sur gnu.org/software/emacs/manual/html_node/emacs/… . En bref, le format pour le début du fichier est: <prefix>-*- var: value[; ...] -*-.

— ivan_pozdeev

38

PEP 263:

la première ou la deuxième ligne doit correspondre à l'expression régulière "codage [: =] \ s * ([- \ w.] +)"

Donc, "en coding: UTF-8 " correspond.

PEP fournit quelques exemples:

#!/usr/bin/python
# vim: set fileencoding=<encoding name> :

# This Python file uses the following encoding: utf-8
import os, sys

— vartec
source

31

Copiez simplement et collez l'instruction ci-dessous en haut de votre programme, cela résoudra les problèmes d'encodage de caractères

#!/usr/bin/env python
# -*- coding: utf-8 -*-

— Harun ERGUL
source

3

À partir d'aujourd'hui - juin 2018

PEP 263 lui-même mentionne l'expression régulière qu'il suit:

Pour définir un encodage de code source, un commentaire magique doit être placé dans les fichiers source en tant que première ou deuxième ligne du fichier, tel que:
# coding=<encoding name>
ou (en utilisant des formats reconnus par les éditeurs populaires):
#!/usr/bin/python
# -*- coding: <encoding name> -*-
ou:
#!/usr/bin/python
# vim: set fileencoding=<encoding name> : 
Plus précisément, la première ou la deuxième ligne doit correspondre à l'expression régulière suivante:
^[ \t\f]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+)

Donc, comme déjà résumé par d'autres réponses, cela correspondra codingà n'importe quel préfixe, mais si vous souhaitez être aussi conforme à PEP que possible (même si, pour autant que je sache, utiliser encodingau lieu de codingne viole pas PEP 263 de quelque manière que ce soit) - s'en tenir à «plain» coding, sans préfixe.

1

Si je ne me trompe pas, la proposition originale pour les encodages de fichier source était d'utiliser une expression régulière pour les deux premières lignes, ce qui permettrait les deux.

Je pense que l'expression régulière était quelque chose du genre coding: suivi de quelque chose.

J'ai trouvé ceci: http://www.python.org/dev/peps/pep-0263/ Quelle est la proposition originale, mais je n'arrive pas à trouver la spécification finale indiquant exactement ce qu'ils ont fait.

J'ai certainement utilisé encoding: avec beaucoup d'effet, donc évidemment cela fonctionne.

Essayez de changer pour quelque chose de complètement différent, comme duhcoding: ...pour voir si cela fonctionne aussi bien.

— Lasse V. Karlsen
source

0

Je soupçonne qu'il est similaire à Ruby - les deux méthodes sont acceptables.

Ceci est largement dû au fait que différents éditeurs de texte utilisent différentes méthodes (c'est-à-dire les deux) de marquage du codage.

Avec Ruby, tant que le premier, ou le second s'il y a une ligne shebang contient une chaîne qui correspond:

coding: encoding-name

et en ignorant les espaces et autres peluches sur ces lignes. (Cela peut souvent être un = au lieu de: aussi).

— Matthew Schinckel
source