- Аннотация
- Терминология
- Мотивация Вложенные объекты с необязательными атрибутами Разбор структурированных данных Другие распространенные шаблоны
- Вложенные объекты с необязательными атрибутами
- Разбор структурированных данных
- Другие распространенные шаблоны
- Спецификация Операторы доступа с учетом 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-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. Однако другие ложные значения, например 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. Такое поведение аналогично ожиданию любой другой переменной, которая может быть 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-aware» также имеют оператор «not-null assertion» !, например, TypeScript [4], C# [8], Dart [9] и Kotlin [12]. Было предложено включить сюда оператор «None-assertion» !. Это было бы особенно полезно в типизированном коде 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 добавлялась бы автоматически для каждого доступа к атрибуту или элементу.
Хотя поначалу это может показаться более простым в написании, такой подход порождает новые проблемы. При использовании явных операторов ?. и ?[ ] пространство входных данных четко определено. Ожидается, что только a, .c и .d могут быть None. Если .b внезапно тоже окажется None, это все равно вызовет AttributeError, так как это было неожиданно. С maybe такого бы не произошло. Такое поведение проблематично, так как оно может незаметно скрывать реальные ошибки. Поскольку результат выражения и так может быть None, пространство потенциальных выходных значений не изменилось, и, следовательно, ошибка не появилась бы.
Если целью является перехват всех исключений AttributeError и TypeError, вместо этого можно использовать блок try-except.
Поскольку операторы ?. и ?[ ] позволили бы разработчикам более явно выражать свои намерения, это предложение отклоняется.
Удалить короткое замыкание (short-circuiting)
Было предложено полностью удалить поведение короткого замыкания, так как его может быть слишком сложно понять. Вместо этого разработчикам следовало бы изменять любой последующий доступ к атрибуту или подписке на их варианты с проверкой на None.
Эта идея сталкивается с некоторыми из тех же проблем, что и «Добавление ключевого слова maybe». Принудительное использование ?. или ?[ ] для атрибутов, которые не являются опциональными, затруднит понимание того, начали ли неопциональные атрибуты .c или .d внезапно возвращать None. Исключение AttributeError было бы подавлено.
Еще одна проблема, особенно для длинных выражений, заключается в том, что все последующие операторы доступа к атрибутам и подписки должны быть изменены, как только хотя бы один атрибут в длинной цепочке становится опциональным. Пропуск хотя бы одного из них может мгновенно привести к новому исключению AttributeError или TypeError.
? Унарный постфиксный оператор
Для обобщения поведения с проверкой на None и ограничения количества вводимых новых операторов рассматривался унарный постфиксный оператор ?. Тогда ?. или ?[ ] можно было бы рассматривать как два отдельных оператора.
Хотя это могло бы немного упростить обучение работе с операторами — всего один новый оператор вместо двух, — это также может быть слишком общим решением в том смысле, что его можно было бы комбинировать с любым другим оператором. Например, неясно, что означали бы следующие выражения:
Даже если предположить, что значение по умолчанию — «если не None, то значение, иначе 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
Было предложено ввести объект Result, аналогичный тому, как сегодня работает asyncio.Future. Выражения, помеченные специальным ключевым словом или синтаксисом, возвращали бы экземпляр Result вместо вычисленного выражения. Фактическое значение можно было бы получить, вызвав .result() или .exception() у этого объекта. С этим можно было бы изящно обрабатывать выражения с проверкой на None.
Хотя это интересная идея, она привела бы к радикальным изменениям в том, как выражения должны записываться и вычисляться сегодня.
Преимущество операторов ?. и ?[ ] заключается в том, что они не сильно меняют результат, за исключением добавления None как возможного возвращаемого значения выражения. Таким образом, они являются лучшим решением для вариантов использования, описанных в разделе «Мотивация».
Протокол No-Value
Операторы доступа с проверкой на None можно было бы обобщить для пользовательских типов, определив протокол, указывающий, когда значение представляет «отсутствие значения». Таким протоколом мог бы быть магический метод __has_value__(self), который возвращает True, если значение следует рассматривать как имеющее значение, и False, если значение следует рассматривать как отсутствие значения.
В разделе спецификации все случаи использования «x is not None» были бы заменены на «x.__has_value__()».
Существует несколько очевидных кандидатов, таких как math.nan и NotImplemented. Однако, хотя их можно интерпретировать как отсутствие значения, эта интерпретация зависит от предметной области. Для самого языка они все равно должны рассматриваться как значения. Например, math.nan.imag хорошо определено (это 0.0), поэтому короткое замыкание math.nan?.imag для возврата None было бы некорректным.
Поскольку None уже определено языком как значение, представляющее «отсутствие значения», эта идея отклоняется.
Использовать существующий синтаксис или ключевое слово
В некоторых комментариях предлагалось использовать существующий синтаксис, например ->, для операторов доступа с проверкой на None, например a->b.c.
Хотя это возможно, оператор -> уже используется в Python для совершенно других целей. Кроме того, большинство других языков, поддерживающих операторы «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.
