- Аннотация
- Терминология
- Мотивация Вложенные объекты с необязательными атрибутами Разбор структурированных данных Другие распространенные паттерны
- Вложенные объекты с необязательными атрибутами
- Разбор структурированных данных
- Другие распространенные паттерны
- Спецификация Операторы доступа с учетом None Короткое замыкание Родительские выражения — группировки Присваивания Выражения Await Изменения AST Изменения грамматики Многострочное форматирование
- Операторы доступа с учетом None Короткое замыкание Родительские выражения — группировки Присваивания Выражения Await
- Короткое замыкание
- Родительские выражения — группировки
- Присваивания
- Выражения Await
- Изменения AST
- Изменения грамматики Многострочное форматирование
- Многострочное форматирование
- Обратная совместимость
- Влияние на безопасность
- Как этому учить
- Эталонная реализация
- Отложенные идеи Оператор объединения ?? и оператор присваивания с объединением ??= Вызовы функций с учетом None Оператор утверждения None Добавление list.get(key)
- Оператор объединения ?? и оператор присваивания с объединением ??=
- Вызовы функций с учетом None
- Оператор утверждения None
- Добавление list.get(key)
- Отвергнутые идеи Операторы с учетом исключений Добавление ключевого слова maybe Удаление короткого замыкания ? Унарный постфиксный оператор Встроенная функция для обхода Функция Maybe Объект результата Протокол отсутствия значения Использование существующего синтаксиса или ключевого слова Отсрочка оператора индексации с учетом None Игнорирование групп для короткого замыкания Изменение основного правила на праворекурсивное
- Операторы с учетом исключений
- Добавление ключевого слова maybe
- Удаление короткого замыкания
- ? Унарный постфиксный оператор
- Встроенная функция для обхода
- Функция Maybe
- Объект результата
- Протокол отсутствия значения
- Использование существующего синтаксиса или ключевого слова
- Отсрочка оператора индексации с учетом None
- Игнорирование групп для короткого замыкания
- Изменение основного правила на праворекурсивное
- Распространенные возражения Трудно читать Легко ошибиться с ?. Неочевидно, что делают ?. и ?[ ] ?. и ?[ ] должны обрабатывать отсутствующие атрибуты Короткое замыкание трудно понять Просто используйте … … условное выражение … выражение match … try … except … … библиотеку для обхода Распространение None в кодовых базах None недостаточно особенный ? последний доступный символ ASCII
- Трудно читать
- Легко ошибиться с ?.
- Неочевидно, что делают ?. и ?[ ]
- ?. и ?[ ] должны обрабатывать отсутствующие атрибуты
- Короткое замыкание трудно понять
- Просто используйте … … условное выражение … выражение match … try … except … … библиотеку для обхода
- … условное выражение
- … выражение match
- … try … except …
- … библиотеку для обхода
- Распространение None в кодовых базах
- None недостаточно особенный
- ? последний доступный символ ASCII
- Сноски
Аннотация
Этот PEP предлагает добавить два новых оператора.
- Оператор «доступа к атрибуту с учетом None» ?.
- Оператор «индексации с учетом None» ?[ ]
Общая идея заключается в предоставлении операторов доступа, которые могут обходить значения None без вызова исключений.
Оба оператора вычисляют левую часть, проверяют, что она не равна None, и только после этого вычисляют выражение целиком. Они примерно эквивалентны:
Терминология
Мотивация
Впервые официально предложенная более десяти лет назад в (ныне отложенном) PEP 505, идея добавления операторов доступа с учетом None существует уже довольно давно и подробно обсуждалась в многочисленных ветках, последними из которых являются [1] и [2]. Этот PEP призван зафиксировать текущее состояние обсуждения и предлагает спецификацию для добавления в язык Python. В отличие от PEP 505, он будет сфокусирован только на двух операторах доступа. Более подробную информацию см. в разделе «Отложенные идеи».
Операторы доступа с учетом None — не новое изобретение. Несколько других современных языков программирования имеют так называемые операторы «учета null» или «опциональной цепочки» (null-aware / optional chaining), включая TypeScript [3], ECMAScript (он же JavaScript) [5], C# [7], Dart [9], Swift [10], Kotlin [11], Ruby [13], PHP [14] и другие.
Общая идея заключается в предоставлении операторов доступа, которые могут обходить значения None без вызова исключений.
Вложенные объекты с необязательными атрибутами
При написании кода на Python часто встречаются объекты с необязательными атрибутами. Доступ к атрибутам, индексам или вызовы функций могут вызывать AttributeError или TypeError во время выполнения, если значение равно None. Чтобы гарантировать, что эти операции не вызовут исключений, часто используют проверки is not None. Даже для довольно простых объектов это часто добавляет вложенность и дублирование кода. Рассмотрим следующий упрощенный пример:
Это также можно записать с использованием выражений присваивания:
Хотя оба варианта корректны, для понимания добавляемых здесь простых проверок требуется больше усилий, чем необходимо. Кроме того, написание этих инструкций и выражений может стать весьма громоздким — настолько, что нередко определенные части просто пропускаются: например, вместо явной проверки is not None полагаются на неявные булевы проверки, либо вместо присваивания временным переменным повторяют предыдущие выражения.
Цель для ?. и ?[ ] состоит в том, чтобы сделать чтение и написание такого рода выражений намного проще, оставаясь при этом предсказуемыми и интуитивно понятными. С помощью этих операторов функцию можно переписать следующим образом:
Здесь символы ? вставляются после каждого необязательного подвыражения, превращая операторы доступа в операторы «доступа к атрибуту с учетом None». В отличие от предыдущего случая, больше не нужно добавлять дополнительные операторы if, присваивания или вложенность. Таким образом, начиная с «обычных» операторов доступа к атрибутам и заменяя их при необходимости на ?., вы получаете простой способ написания таких выражений.
Разбор структурированных данных
Операторы ?. и ?[ ] также могут помочь при обходе структурированных данных, часто поступающих из JSON и разбираемых как вложенные словари и списки. Однако стоит отметить, что операторы НЕ обрабатывают отсутствующие атрибуты/данные. В таких случаях, по крайней мере для словарей, полезным вспомогательным методом является dict.get(key).
Запись с использованием ?. и ?[ ] будет выглядеть следующим образом:
Другие распространенные паттерны
Коллекция дополнительных паттернов, которые можно улучшить с помощью ?. и ?[ ]. Цель состоит не в том, чтобы перечислить все возможные варианты использования, а в том, чтобы помочь распознать эти паттерны, которые часто скрываются на самом видном месте. Имена атрибутов и функций были сокращены.
Примечание
Большинство приведенных ниже паттернов не являются полностью идентичными. Как упоминалось ранее, для фильтрации значений None часто используются логические выражения. Однако другие ложные значения (falsy), например False, "", 0, [], {} или пользовательские объекты, переопределяющие __bool__, также отфильтровываются. Если код опирается на это свойство, выражение не всегда можно заменить на ?. или ?[ ].
Спецификация
Операторы доступа с учетом None
Добавляются два новых оператора: ?. и ?[ ]. Оба оператора сначала вычисляют левую часть (базу). Результат кэшируется, чтобы выражение не вычислялось повторно. Проверяется, не равен ли результат None, и только после этого оставшаяся часть выражения (хвост) вычисляется так, как если бы использовался обычный доступ к атрибутам или индексам.
База может быть заменена любым количеством выражений, включая выражения в скобках, в то время как хвост ограничен доступом к атрибутам, индексам, их вариантам с учетом None и выражениями вызовов.
Короткое замыкание
Если левая часть (база) для ?. или ?[ ] вычисляется как None, оставшееся выражение (хвост) пропускается, а вместо этого результат устанавливается в None. Это охватывает все элементы в хвостовой части, включая вычисление аргументов функций или индексов. AttributeError при обращении к члену None или TypeError при попытке получить индекс None опускаются. Следовательно, нет необходимости менять последующие . или [ ] в правой части только потому, что ранее используется ?. или ?[ ].
Операторы доступа с учетом None будут применять короткое замыкание только к выражениям, содержащим первичные выражения (имя, доступ к атрибуту, индекс, их эквиваленты с учетом None и выражения вызова). Как правило, короткое замыкание прекращается при достижении любого оператора, кроме ., [ ], ?., ?[ ].
Другой способ посмотреть на это — задать вопрос, можно ли извлечь часть выражения и определить ее как переменную без изменения ее смысла. Если это так, то короткое замыкание, скорее всего, будет нарушено. Например, аргументы функций или индексы вычисляются сами по себе и не вызывают короткое замыкание оставшегося хвоста внешнего выражения.
Выражения в скобках — группировка
Использование ?. и ?[ ] внутри групп возможно. В дополнение к правилам, изложенным в предыдущем разделе, короткое замыкание также будет прекращаться в конце группы. Например, выражение (a?.b).c вызовет AttributeError для .c, если a равен None. Это концептуально идентично извлечению содержимого группы и сохранению результата во временной переменной перед подстановкой его обратно в исходное выражение.
Распространенные варианты использования операторов доступа с учетом None в группах — это логические или условные выражения, которые могут предоставить запасное значение в случае, если первая часть вычисляется как None.
Присваивания
Выражения с учетом None могут использоваться только в контексте загрузки (Load). Присваивания не разрешены и вызовут SyntaxError.
Это не применяется, если выражение с учетом None является лишь частью более крупного выражения и вычисляется само по себе, например, в качестве аргумента функции.
Выражения Await
Операции доступа с учетом None разрешены в выражениях await. Разработчик должен убедиться, что они не возвращают None во время выполнения, в противном случае вызывается TypeError. Такое поведение аналогично ожиданию (await) любой другой переменной, которая может быть None.
Изменения AST
Добавлены два новых узла AST: NoneAwareAttribute и NoneAwareSubscript. Они являются аналогами существующих узлов Attribute и Subscript. Примечательно, что здесь нет атрибута expr_context, поскольку новые узлы сами по себе не поддерживают присваивания, и поэтому контекстом всегда будет Load. Кроме того, для всех узлов выражений добавлен необязательный атрибут group. Он устанавливается в 1, если выражение является самым верхним узлом в группе, и в 0 в противном случае.
Изменения грамматики
Добавлен новый токен ?. Кроме того, правило первичной грамматики обновлено и теперь включает none_aware_attribute и none_aware_subscript.
Многострочное форматирование
Использование двух отдельных токенов для выражения ?. и ?[ позволяет разработчикам вставлять пробел или разрыв строки по мере необходимости. Для многострочных выражений это позволяет добавлять ? к необязательному подвыражению, в то время как . или [ можно перенести на следующую строку. Это задумано исключительно как опция для разработчиков. Каждый волен выбирать стиль, который соответствует его потребностям, особенно форматтеры кода могут предпочесть стиль, который лучше соответствует их существующим предпочтениям. Пример того, что возможно:
Обратная совместимость
Существующие программы продолжат работать как есть. До сих пор код, использующий либо ?. либо ?[ ], вызывал SyntaxError.
Влияние на безопасность
Данное предложение не несет в себе новых рисков безопасности.
Как этому учить
После того как учащиеся узнают, как работают операторы доступа к атрибутам . и индексу [ ], они могут изучить варианты «с учетом None» для обоих случаев.
Учащимся может быть полезно воспринимать ?. и ?[ ] как комбинацию двух разных действий. Сначала суффикс ? представляет собой проверку подвыражения на то, что оно не равно None, с коротким замыканием в случае неудачной проверки. Если проверка проходит успешно, доступ к атрибуту и индексу выполняется как обычно.
Опытные разработчики могут заметить, что после изучения PEP они начинают замечать шаблоны, описанные в разделе «Мотивация», в своих собственных кодовых базах.
Эталонная реализация
Эталонная реализация доступна по адресу https://github.com/cdce8p/cpython/tree/pep823-none-aware-access-operators. Онлайн-демонстрацию можно протестировать по адресу https://pep823-and-pep824-demo.pages.dev/.
Отложенные идеи
Оператор объединения ?? и оператор объединения с присваиванием ??=
В PEP 505 также предлагалось добавить оператор «объединения с None» ?? и оператор «присвоения с объединением с None» ??=. Поскольку операторы доступа с учетом None имеют свои собственные варианты использования, операторы объединения были перенесены в отдельный документ, см. PEP 824. Оба предложения могут приниматься независимо друг от друга.
Вызовы функций с учетом None
Операторы доступа с учетом None работают для доступа по атрибуту и индексу. Естественно задать вопрос, должен ли существовать вариант, который работает для вызовов функций. Он может быть записан как a.foo?(), что было бы эквивалентно:
Это было отложено на том основании, что предлагаемые операторы предназначены для помощи с вложенными объектами с необязательными атрибутами и синтаксическим анализом структурированных данных, а не для обхода произвольных иерархий классов.
Временным решением было бы написать a.foo?.__call__(arguments).
Оператор утверждения None
В нескольких языках программирования с операторами «с учетом null» также есть оператор «утверждения не-null» !, например, в TypeScript [4], C# [8], Dart [9] и Kotlin [12]. Было предложено включить сюда оператор «утверждения None» !. Это было бы особенно полезно в типизированном коде Python, где средства проверки типов не могут статически вывести, что переменная с необязательным (могущим быть None) значением не может быть None в некоторых контекстах.
Этот PEP сфокусирован на операторах доступа с учетом None, поэтому данное предложение выходит за рамки рассмотрения.
Добавление list.get(key)
Было предложено добавить метод .get(key) в объекты list и tuple, аналогично существующему методу dict.get. Это могло бы еще больше упростить синтаксический анализ структурированных данных, так как больше не нужно было бы проверять, достаточно ли длинный список или кортеж, прежде чем пытаться получить n-й элемент, избегая возможного IndexError. Хотя эта идея потенциально полезна, она выходит за рамки данного PEP.
Отвергнутые идеи
Операторы с учетом исключений
Возможно, причиной для прерывания выражения с помощью короткого замыкания при обнаружении None является избежание AttributeError или TypeError, которые возникли бы при обычных обстоятельствах. Вместо проверки на None было предложено, чтобы ?. и ?[ ] могли вместо этого обрабатывать AttributeError и TypeError и пропускать оставшуюся часть выражения. Аналогично вложенным блокам try-except.
Хотя технически это бы работало, совершенно неясно, каким должен быть результат в случае перехвата ошибки. Кроме того, такой подход скрывал бы реальные проблемы, такие как опечатка в имени атрибута, которая вызвала бы AttributeError. Кроме того, уже существуют устоявшиеся паттерны для обработки такого рода ошибок в виде getattr и dict.get(key).
Поскольку перехват исключений был бы неожиданным и скрывал бы потенциальные ошибки, этот подход отклонен.
Добавить ключевое слово maybe
Операторы доступа с проверкой на None проверяют наличие None только в том месте, где они используются. Если несколько атрибутов в выражении могут возвращать None, может потребоваться добавлять их несколько раз: a?.b.c?[0].d?.e(). Было предложено вместо этого добавить новое мягкое ключевое слово maybe в качестве префикса для выражения: maybe a.b.c[0].d.e(). В таком случае проверка на None добавлялась бы автоматически для каждого обращения к атрибуту и элементу.
Хотя поначалу это может казаться более простым в написании, такой подход порождает новые проблемы. При использовании явных операторов ?. и ?[ ][/L1]] пространство входных данных четко определено. Ожидается, что значение None могут принимать только a, .c и .d. Если .b внезапно тоже окажется равным None, это все равно вызовет ошибку AttributeError, поскольку это было непредвиденно. С ключевым словом maybe такого бы не произошло. Такое поведение проблематично, так как оно может незаметно скрывать реальные ошибки. Поскольку результат выражения и так может быть равен None, пространство потенциальных результатов не изменилось, и поэтому никакая ошибка не появится.
Если целью является перехват всех ошибок AttributeError и TypeError, вместо этого можно использовать блок try-except.
Поскольку операторы ?. и ?[ ][/L1]] позволили бы разработчикам более явно выражать свои намерения, это предложение отклонено.
Удалить короткое замыкание
Было предложено полностью удалить поведение короткого замыкания, поскольку оно может быть слишком сложным для понимания. Вместо этого разработчикам следовало бы изменять любые последующие обращения к атрибутам или индексам на их варианты с проверкой на None.
Эта идея имеет те же проблемы, что и предложение добавить ключевое слово maybe. Принудительное использование ?. или ?[ ][/L1]] для атрибутов, которые не являются опциональными, приведет к тому, что будет сложно узнать, если неопциональные атрибуты .c или .d внезапно тоже начнут возвращать None. Ошибка AttributeError была бы заглушена.
Еще одна проблема, особенно для длинных выражений, заключается в том, что все последующие операторы доступа к атрибутам и индексам необходимо изменять, как только хотя бы один атрибут в длинной цепочке становится опциональным. Пропуск хотя бы одного из них может мгновенно вызвать новую ошибку AttributeError или TypeError.
? Унарный постфиксный оператор
Для генерализации поведения с проверкой на None и ограничения количества вводимых новых операторов рассматривался унарный постфиксный оператор ?[/L1]]. В таком случае ?. или ?[ ][/L1]] можно было бы рассматривать как два отдельных оператора.
Хотя это могло бы немного упростить обучение работе с операторами (один новый оператор вместо двух), это также может быть слишком универсальным в том смысле, что его можно комбинировать с любым другим оператором. Например, неясно, что будут означать следующие выражения:
Даже если предполагается стандартный смысл is not None else None, эти выражения в какой-то момент, скорее всего, вызовут ошибки.
Такая степень обобщения бесполезна. Операторы доступа с проверкой на None были намеренно выбраны для того, чтобы упростить доступ к значениям в вложенных объектах с опциональными атрибутами.
Если будущие PEP захотят представить новые операторы для доступа к атрибутам или вызова методов, например, оператор цепочки вызовов, было бы целесообразно рассмотреть вопрос о том, может ли в этот момент пригодиться его вариант с проверкой на None.
Встроенная функция для обхода
Существует ряд библиотек, которые предоставляют те или иные функции обхода объектов. Самой популярной, вероятно, является glom [15]. К другим относятся jmespath [16] и nonesafe [17]. Идея обычно заключается в том, чтобы передать объект и атрибуты для поиска в виде строки функции, которая обрабатывает вычисление. Было предложено добавить функцию traverse или deepget в стандартную библиотеку.
Хотя эти библиотеки работают и имеют свои варианты применения (в частности, glom предоставляет отличный интерфейс для извлечения и объединения множества точек данных из глубоко вложенных объектов), у них есть и определенные недостатки. Передача атрибутов поиска в виде строки означает, что зачастую больше нет подсказок от среды разработки (IDE). Проверка типов для таких выражений также ограничена. Кроме того, обычные вызовы функций не могут обеспечить короткое замыкание, поэтому их все равно пришлось бы комбинировать с присваиванием и условными выражениями.
Функция maybe
Другим предложением было добавить функцию maybe, которая возвращала бы либо экземпляр Something, либо экземпляр Nothing. Nothing переопределял бы специальные методы (dunder methods), чтобы разрешить выстраивание цепочек для опциональных атрибутов.
Пакет Python под названием pymaybe [18] дает приблизительное представление о таком подходе. Пример может выглядеть следующим образом:
Хотя это могло бы работать, Something и Nothing являются лишь классами-обертками для фактических значений, что создает собственные трудности. Например, чтобы отфильтровать None в последующей операции, проверка is not None всегда будет возвращать True, и вместо этого потребуется использовать .is_some(). Это затруднило бы внедрение такого подхода в крупной кодовой базе и снизило бы его полезность. Кроме того, любая реализация на чистом Python на самом деле не может обеспечить короткое замыкание выражения. Максимум, что она может сделать, — это реализовать пустые операции (no-ops) в классах-обертках.
Поэтому встроенная функция maybe для поддержки доступа к вложенным объектам с опциональными атрибутами отклонена.
Result object
Было предложено ввести объект Result, аналогичный тому, как сегодня работает asyncio.Future. Выражения, отмеченные специальным ключевым словом или синтаксисом, в таком случае возвращали бы экземпляр Result вместо вычисленного выражения. Фактическое значение можно было бы получить, вызвав для него .result() или .exception(). При этом появилась бы возможность корректно обрабатывать выражения с проверкой на None.
Хотя это интересная идея, она стала бы радикальным изменением того, как выражения должны писáться и вычисляться в настоящее время.
Преимущество операторов ?. и ?[ ][/L1]] заключается в том, что они не сильно меняют результат, помимо добавления None в качестве возможного возвращаемого значения выражения. Таким образом, они являются более лучшим решением для сценариев использования, описанных в разделе «Мотивация».
Протокол отсутствия значения (No-Value Protocol)
Операторы доступа с проверкой на None можно было бы распространить на пользовательские типы, определив протокол для обозначения того, когда значение представляет «отсутствие значения». Таким протоколом может быть специальный метод __has_value__(self), который возвращает True, если значение следует рассматривать как существующее, и False, если значение следует рассматривать как отсутствие значения.
В разделе спецификации все использования x is not None были бы заменены на x.__has_value__()[/L1]].
Есть несколько очевидных кандидатов, таких как math.nan и NotImplemented. Однако, хотя их можно интерпретировать как представляющие отсутствие значения, эта интерпретация зависит от контекста предметной области. Для самого языка они все равно должны рассматриваться как значения. Например, выражение math.nan.imag определено корректно (оно равно 0.0), поэтому применение короткого замыкания к math.nan?.imag для возврата None было бы некорректным.
Поскольку None уже определен в языке как значение, представляющее «отсутствие значения», эта идея отклонена.
Использовать существующий синтаксис или ключевое слово
В некоторых комментариях предлагалось использовать существующий синтаксис, например ->, для операторов доступа с проверкой на None, например a->b.c.
Хотя это и возможно, оператор -> уже используется в Python совсем для других целей. Кроме того, большинство других языков, поддерживающих операторы «с учетом null» или «опциональной цепочки» (null-aware / optional chaining), используют ?.. Исключениями являются Ruby [13] с &. или PHP [14] с ?->. Символ ? пока не имеет назначенного значения в Python. Таким образом, имеет смысл принять наиболее распространенное написание для операторов доступа с учетом None. Особенно учитывая, что оно также хорошо сочетается с «обычными» операторами . и [ ].
Отложить оператор индексации с учетом None
Предметом обсуждения был оператор ?[ ]. Некоторые считали, что его можно слишком легко пропустить в выражении вроде a.b?[c]. Чтобы продвинуть дискуссию вперед, было предложено отложить этот оператор на потом.
Хотя сужение области видимости часто помогает вообще сдвинуться с мертвой точки, оператор ?[ ] необходим для эффективного получения элементов из опциональных объектов. В то время как для словарей подходящей альтернативой является использование d?.get(key), для общих объектов разработчикам пришлось бы прибегать к o?.__getitem__(key).
Более того, любой будущий PEP, посвященный только ?[ ], вероятно, должен был бы снова включить множество аргументов и возражений, перечисленных в этом документе. Поэтому имеет смысл включить оба оператора в один и тот же PEP.
Хотя добавление list.get(key), как предлагается в Add list.get(key), уменьшило бы потребность в ?[ ] для списков и кортежей и, таким образом, стало бы ценным дополнением к самому языку, оно не устраняет необходимость для произвольных объектов, реализующих пользовательский метод __getitem__.
Игнорировать группы для короткого замыкания
В более ранней версии этого PEP предполагалось, что поведение короткого замыкания не должно зависеть от группировки. Предполагалось, что короткое замыкание и так будет нарушаться для более сложных групповых выражений вроде (a?.b or c).d из-за поведения, описанного в разделе «Короткое замыкание», в то время как для более простых, вроде (a?.b).c, группировка считалась тривиальной и выражение было бы эквивалентно a?.b.c. Преимущество заключалось в том, что разработчикам не пришлось бы выискивать группировки при вычислении простых выражений. До тех пор, пока используется какой-либо оператор доступа с учетом None и выражение не прерывается каким-либо другим несвязанным оператором, оно возвращало бы None вместо возбуждения исключения AttributeError или TypeError.
Это предложение было отклонено в пользу спецификации, описанной в разделе «Выражения в скобках — группировка», поскольку оно нарушает принцип подстановки. Выражение (a?.b).c должно вести себя одинаково независимо от того, написано ли a?.b внутри группы или определено как отдельная переменная.
Кроме того, определение поведения короткого замыкания таким образом было бы отклонением от уже устоявшегося поведения в таких языках, как JS [6] и C# [7].
Изменить первичное правило на праворекурсивное
Первичное правило грамматики в том виде, в каком оно определено [19], является леворекурсивным. Это может затруднить понимание логики, особенно в отношении поведения короткого замыкания и выражений в скобках.
Поэтому было предложено сделать операторы доступа с учетом None частью первичного правила праворекурсивными. Выражение a.b?.c[0].func() тогда бы грубо разбиралось как:
По сравнению с этим, предлагаемые изменения грамматики намеренно сведены к минимуму. Операторы доступа с учетом None должны вести себя более или менее как прямая замена для . и [ ], но с поведением, описанным в этом PEP.
Распространенные возражения
Трудно читать
Легко ошибиться в ?.
Было отмечено, что слишком легко перепутать символы в ?. .
