Почему Python3 различает ascii и utf-8

-1

Все символы ascii могут быть представлены utf-8 (первые семь бит пространства). Использование исключительно utf-8 может значительно упростить string handling. Предоставлено utf-8 не является форматом фиксированной длины и поэтому имеет определенные штрафы за производительность по отношению к ascii, но у меня есть ощущение, что python обычно идет за pythonic перед исполнением.Почему Python3 различает ascii и utf-8

Мой вопрос: Был ли когда-либо были решены, почему python3 реализует строки таким образом, вместо того, чтобы utf-8 исключительно? Таким образом, он не представляет его как поток бит с различными представлениями, но всегда с кодировкой utf-8.

Я не ищу личных мнений пользователей SO, а для PEP или расшифровки от диктатора, обращаясь к этому самому вопросу.

источник

2016-07-22 magu_

Python3 * does * использует кодировку utf-8 по умолчанию, поэтому я понятия не имею, что ваш вопрос действительно задает ... – wim

@wim Я попытался сделать его более понятным. Хотя он использует utf-8 по умолчанию, по-прежнему существует двоичная строка, которая может, например, приводить к неприятным ошибкам при попытке сопоставить строки. Мой вопрос: почему версия языка не была разработана таким образом, чтобы разрешить только один тип представления. –

Это * был * разработан таким образом, и одним типом представления является представление 'str'. Оба '' utf-8'' и '' ascii'' являются кодировками. Нет такой вещи, как объект utf-8 str. – wim

От PEP 393:

Обоснование

Есть два класса жалоб о текущей реализации типа Юникода: на системах, которые поддерживают только UTF-16, пользователи жалуются , что не-BMP символов не поддерживаются должным образом. В системах, использующих UCS-4 внутренне (а также иногда в системах с использованием UCS-2), есть жалоба на то, что строки Unicode занимают слишком много памяти - особенно по сравнению с Python 2.x, где тот же код часто используется ASCII строки (то есть байтовые строки, закодированные в ASCII). При предлагаемом подходе Строки Unicode только для ASCII снова будут использовать только один байт на символ; , сохраняя при этом эффективную индексацию строк, содержащих символы не BMP (поскольку строки, содержащие их, будут использовать 4 байта на символ ).

Одной из проблем с подходом является поддержка существующих приложений (например, модулей расширения). Для совместимости могут быть вычислены избыточные представления . Заявки рекомендуется поэтапно отключать от конкретное внутреннее представление, если это возможно. Взаимодействие с в других библиотеках часто требует своего рода внутреннего представления , спецификация выбирает UTF-8 как рекомендуемый способ: раскрытия строк на C-код.

Для многих строк (например, ASCII), множественные представления могут фактически памяти акций (например, самая короткая форма может быть совместно с формой UTF-8 , если все символы ASCII). При таком совместном использовании сокращаются служебные данные . Если представления действительно делят данные , также можно опустить поля структуры, уменьшая размер базовых .

Если это не видно из приведенного выше текста:

Мы хотим, чтобы большинство строк представление пространст- эффективным
Мы хотим эффективной индексации по возможности
Мы хотим быть совместим со всеми системами и обеспечивает все Unicode для всех систем

Результат состоит в том, что использование одного внутреннего представления приведет к по меньшей мере одному из ограничений.

источник

2016-07-22 16:40:26 Bakuriu

Спасибо, что выкопали это. Я могу следовать их рассуждениям, хотя я не уверен, что в итоге получится тот же вывод. Поскольку все управление памятью могло быть сделано под капотом с флагами в коде C. Но я думаю, что это основано на мнениях. –

@magu_ Я не понимаю, что вы подразумеваете под «флагами в коде C». Если у вас есть только одно представление utf-8, вы теряете эффективную индексацию всякий раз, когда используете символы с более чем одним байтом. При текущей реализации, когда вы используете широкие символы, вы получаете меньше эффективности памяти (хотя это зависит от *), но с лучшей эффективностью индексации. Есть еще случаи, когда индексация O (1) не может быть достигнута, но они намного реже, чем просто использование utf-8, где * большинство * неанглийских тестов будут страдать от плохих результатов. – Bakuriu

Мое рассуждение состояло в том, что внутренние элементы python могли внутренне выполнять ветвление, в зависимости от того, когда любой символ в строке имеет значение больше или меньше 127. Таким образом, можно было бы быстро индексировать быструю индексацию O (1) для ascii и медленного O (n) индексирование для utf-8. Поскольку 'strings' являются неизменяемыми в' python', эта информация (любой символ размером более 127) может быть сохранена как флаг при создании объекта. –

Почему Python3 различает ascii и utf-8

ответ

Обоснование

Смежные вопросы