Najlepszy sposób na konwersję ciągu na bajty w Pythonie 3?

Wydaje się, że istnieją dwa różne sposoby konwersji ciągu na bajty, jak widać w odpowiedziach na TypeError: „str” nie obsługuje interfejsu bufora

Która z tych metod byłaby lepsza, czy bardziej Pythonic? Czy to tylko kwestia osobistych preferencji?

b = bytes(mystring, 'utf-8')

b = mystring.encode('utf-8')

Jeśli spojrzysz na dokumenty bytes, wskazuje to na bytearray:

bytearray ([source [, kodowanie [, błędy]]])

Zwraca nową tablicę bajtów. Typ bytearray to zmienna sekwencja liczb całkowitych z zakresu 0 <= x <256. Posiada większość zwykłych metod sekwencji zmiennych, opisanych w Zmiennych typach sekwencji, a także większość metod typu bajtów, patrz Bajty i Metody tablicy bajtów.

Opcjonalnego parametru źródłowego można użyć do zainicjowania tablicy na kilka różnych sposobów:

Jeśli jest to ciąg, musisz również podać parametry kodowania (i opcjonalnie błędy); bytearray () następnie konwertuje ciąg na bajty za pomocą str.encode ().

Jeśli jest liczbą całkowitą, tablica będzie miała ten rozmiar i zostanie zainicjowana bajtami zerowymi.

Jeśli jest to obiekt zgodny z interfejsem bufora, do zainicjowania tablicy bajtów zostanie użyty bufor tylko do odczytu obiektu.

Jeśli jest iterowalna, musi być iterowalna z liczb całkowitych z zakresu 0 <= x <256, które są używane jako początkowa zawartość tablicy.

Bez argumentu tworzona jest tablica o rozmiarze 0.

bytesMoże więc zrobić znacznie więcej niż tylko kodowanie łańcucha. Pythonic pozwala na wywołanie konstruktora z dowolnym typem parametru źródłowego, który ma sens.

Myślę, że w przypadku kodowania ciągu some_string.encode(encoding)jest to bardziej Pythonic niż używanie konstruktora, ponieważ jest to najbardziej samok dokumentujące - „weź ten ciąg i zakoduj go za pomocą tego kodowania” jest wyraźniejsze niż bytes(some_string, encoding)- nie ma wyraźnego czasownika podczas używania konstruktor.

Edycja: sprawdziłem źródło Python. Jeśli przekażesz ciąg Unicode, aby bytesużyć CPython, wywołuje PyUnicode_AsEncodedString , który jest implementacją encode; więc po prostu omijasz poziom pośredni, jeśli nazywasz encodesiebie.

Zobacz także komentarz Serdalisa - unicode_string.encode(encoding)jest również bardziej Pythoniczny, ponieważ jego odwrotność jest byte_string.decode(encoding)i symetria jest ładna.

To łatwiejsze niż się wydaje:

my_str = "hello world"
my_str_as_bytes = str.encode(my_str)
type(my_str_as_bytes) # ensure it is byte representation
my_decoded_str = my_str_as_bytes.decode()
type(my_decoded_str) # ensure it is string representation

Absolutnie najlepszym sposobem jest ani o 2, ale 3rd. Pierwszy parametr ma wartość domyślną od czasu Python 3.0. Zatem najlepszym sposobem jestencode 'utf-8'

b = mystring.encode()

Będzie to również szybsze, ponieważ domyślny argument nie powoduje ciągu "utf-8"w kodzie C, ale NULL, co jest znacznie szybsze do sprawdzenia!

Oto kilka terminów:

In [1]: %timeit -r 10 'abc'.encode('utf-8')
The slowest run took 38.07 times longer than the fastest. 
This could mean that an intermediate result is being cached.
10000000 loops, best of 10: 183 ns per loop

In [2]: %timeit -r 10 'abc'.encode()
The slowest run took 27.34 times longer than the fastest. 
This could mean that an intermediate result is being cached.
10000000 loops, best of 10: 137 ns per loop

Mimo ostrzeżenia czasy były bardzo stabilne po wielokrotnych przejazdach - odchylenie wynosiło tylko ~ 2 procent.

Używanie encode()bez argumentu nie jest zgodne z Python 2, ponieważ w Python 2 domyślnym kodowaniem znaków jest ASCII .

>>> 'äöä'.encode()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)