Python: данные по сравнению с текстом?
. сетевая дистанционная работа встроена в .net, чтобы сделать внутреннюю коммуникацию процесса. Если Вы будете использовать это, они продолжат поддерживать и возможно улучшать его в будущих версиях. Именованные каналы не дают Вам обещание улучшений в будущих версиях .net
2 ответа
Вкратце, способ обработки текста и данных в Py3k, возможно, может быть самым "критическим" изменением в языке. Зная и по возможности избегая ситуаций, когда некоторая логика Python 2.6 будет работать иначе, чем в 3.x, мы можем облегчить миграцию, когда это произойдет. Тем не менее, мы должны ожидать, что некоторые части логики 2.6 могут потребовать особого внимания и модификаций, например, для работы с отдельными кодировками и т. Д.
Идея, лежащая в основе предложения BDFL на слайде 14, вероятно, состоит в том, чтобы начать « с использованием » те же типы, которые поддерживает Py3k (и только они), а именно строки Unicode для строк (тип str ) и 8-битные последовательности байтов для «данных» (тип bytes ).
Термин « с использованием » в предыдущем предложении используется довольно свободно, поскольку семантика и связанное хранение / кодирование для этих типов различаются между версиями 2.6 и 3.x. В Python 2.6 тип байтов и связанный с ним буквальный синтаксис (b'xyz ') просто сопоставляются с типом str. Поэтому
# in Py2.6
>>'mykey' == b'mykey'
True
b'mykey'.__class__
<class 'str'>
# in Py3k
>>>'mykey' == b'mykey'
False
b'mykey'.__class__
<class 'bytes'>
Чтобы ответить на ваш вопрос [в примечаниях ниже], в 2.6, используете ли вы b'xyz 'или' xyz ', Python понимает это как одно и то же и одно: str. Важно то, что вы понимаете их как [потенциально / в будущем] два разных типа с разными целями :
- str для текстовой информации и
- байтов для последовательностей октетов, хранящих любые данные под рукой.
Например, снова говоря близко к вашему примеру / вопросу, в Py3k вы сможете иметь словарь с двумя элементами, имеющими одинаковые ключи, один с b'mykey, а другой с mykey, однако в версии 2.6 это невозможно, так как эти два ключа действительно одинаковы; важно то, что вы знаете такие вещи и избегаете (или явно помечаете специальным образом в коде) ситуаций, когда код 2.6 не будет работать в 3.x.
В Py3k str - это абстрактная строка в Юникоде. , последовательность кодовых точек (символов) Unicode, и Python занимается преобразованием этого в / из его закодированной формы, какой бы кодировкой ни была (как программист, вы говорите о кодировке, но в то время, когда вы имеете дело со строковыми операциями и, таким образом, вы не нужно беспокоиться об этих деталях). Напротив, байты - это последовательность 8-битных «вещей», семантика и кодировка которых полностью оставлены на усмотрение программиста.
Итак, хотя Python 2.6 не видит разницы, явно используя bytes () / b ' ... 'или str () / u' ... ', вы ...
- ... подготовите себя и свою программу к предстоящим типам и семантике Py3k
- ... облегчите задачу автоматическое преобразование (инструмент 2to3 или другое) исходного кода, при этом b в b '...' останется, а u из u '...'
Ответ на ваш первый вопрос прост: в Python 2.6 вы можете делать то, к чему привыкли. Но, если хотите, вы можете переключиться на стандарты Py3k, набрав:
from __future__ import unicode_literals
Ваш второй вопрос требует уточнения:
Строки - это данные, которые печатаются как символы человека. Не только в Python, но и в каждом языке (о котором я знаю) есть свой подход к работе со строками.
Однако общее основание - это кодирование. Кодировки - это способ сопоставления последовательностей байтов с глифами (т. Е. В основном печатными символами).
Python предлагает простой способ преодолеть сложности управления кодировками (когда вы помещаете строковые литералы в свой код).
Давайте посмотрим на очень простой пример:
>>> len("Mañana")
7
Я вижу только 6 символов. Поэтому я ожидаю, что len вернет 6. Где этот лишний «символ» приходящий из? Ну, в UTF-8 символ - представлен двумя байтами. До Py3k строковые литералы были просто последовательностями байтов. Итак, Python видит эту строку как байты и считает их все: Ma \ xc3 \ xb1ana .
Однако, если я выполню следующее:
>>> len(u"Mañana")
6
Итак, Python «знает» точно, что 2- Последовательности байтов для «ñ» следует рассматривать как одну букву.
Это ни в коем случае не является исключительным для Python. Следующий сценарий PHP показывает такое же поведение:
manu@pavla:~$ php <<EOF
<?php
echo strlen("Mañana")."\n";
?>
EOF
7
Решение PHP оказывается более сложным:
manu@pavla:~$ php <<EOF
<?php
echo mb_strlen("Mañana", "utf-8")."\n";
?>
EOF
6
Обратите внимание, я должен заменить mb_strlen на strlen , и я должен передать utf-8 (кодировка) в качестве второго аргумента.
Предупреждение: строки, предоставляемые пользователем, обычно бывают байтами, а не строками Unicode. Так что вам нужно позаботиться об этом. См. Больше на http://mail.python.org/pipermail/python-list/2008-July/139193.html