Poprawny sposób definiowania kodowania kodu źródłowego w Pythonie

PEP 263 definiuje sposób deklarowania kodowania kodu źródłowego w Pythonie.

Zwykle pierwsze 2 wiersze pliku Pythona powinny zaczynać się od:

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

Ale widziałem wiele plików zaczynających się od:

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

=> kodowanie zamiast kodowania .

Jaki jest więc prawidłowy sposób deklarowania kodowania pliku?

Czy kodowanie jest dozwolone, ponieważ używane wyrażenie regularne jest leniwe? Czy jest to po prostu kolejna forma deklarowania kodowania pliku?

Zadaję to pytanie, ponieważ PEP nie mówi o kodowaniu , po prostu mówi o kodowaniu .

Sprawdź dokumenty tutaj :

„Jeśli komentarz w pierwszej lub drugiej linii skryptu Pythona pasuje do wyrażenia regularnego coding[=:]\s*([-\w.]+), komentarz ten jest przetwarzany jako deklaracja kodowania”

„Zalecane formy tego wyrażenia to

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

który jest rozpoznawany również przez GNU Emacs i

# vim:fileencoding=<encoding-name>

który jest rozpoznawany przez VIM Brama Moolenaara. "

Możesz więc umieścić prawie wszystko przed częścią „kodowanie”, ale trzymaj się „kodowania” (bez przedrostka), jeśli chcesz być w 100% zgodny z zaleceniami python-docs.

Mówiąc dokładniej, musisz użyć wszystkiego, co jest rozpoznawane przez Python i określone oprogramowanie do edycji, z którego korzystasz (jeśli w ogóle coś potrzebuje / akceptuje). Np. codingForma jest rozpoznawana (po wyjęciu z pudełka) przez GNU Emacsa, ale nie przez Vima (tak, bez powszechnej zgody, jest to zasadniczo wojna o wpływy ).

PEP 263:

pierwsza lub druga linia musi pasować do wyrażenia regularnego „kodowanie [: =] \ s * ([- \ w.] +)”

Zatem „en coding: UTF-8 ” pasuje.

PEP podaje kilka przykładów:

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

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

Po prostu skopiuj poniższą instrukcję wklej w górnej części programu, aby rozwiązać problemy z kodowaniem znaków

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

Stan na dzień dzisiejszy - czerwiec 2018 r

PEP 263 sam wspomina wyrażenie regularne, które następuje:

Aby zdefiniować kodowanie kodu źródłowego, w plikach źródłowych należy umieścić magiczny komentarz jako pierwszy lub drugi wiersz w pliku, na przykład:

# coding=<encoding name>

lub (przy użyciu formatów rozpoznawanych przez popularne edytory):

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

lub:

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

Dokładniej, pierwsza lub druga linia musi pasować do następującego wyrażenia regularnego:

^[ \t\f]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+)

Tak więc, jak już podsumowano w innych odpowiedziach, będzie pasować codingdo dowolnego przedrostka, ale jeśli chcesz być tak zgodny z PEP, jak to tylko możliwe (nawet jeśli, o ile wiem, używanie encodingzamiast codingnie narusza PEP 263 w jakikolwiek sposób) - trzymaj się „zwykłego” coding, bez przedrostków.

Jeśli się nie mylę, oryginalna propozycja kodowania plików źródłowych polegała na użyciu wyrażenia regularnego w pierwszych kilku wierszach, co pozwoliłoby na jedno i drugie.

Myślę, że wyrażenie regularne było czymś w rodzaju, coding:po którym następuje coś.

Znalazłem to: http://www.python.org/dev/peps/pep-0263/ Co jest oryginalną propozycją, ale nie mogę znaleźć ostatecznej specyfikacji określającej dokładnie, co zrobili.

Z pewnością przywykłem encoding:do świetnego efektu, więc oczywiście to działa.

Spróbuj zmienić na coś zupełnie innego, na przykład duhcoding: ...sprawdź, czy to działa równie dobrze.

Podejrzewam, że jest podobny do Rubiego - każda metoda jest w porządku.

Dzieje się tak głównie dlatego, że różne edytory tekstu używają różnych metod (tj. Tych dwóch) oznaczania kodowania.

W Rubim, o ile pierwsza lub druga, jeśli istnieje linia shebang, zawiera ciąg pasujący:

coding: encoding-name

i ignorując wszelkie spacje i inne kłaczki w tych wierszach. (Często może to być również = zamiast:).