Многострадальный релиз

Эпопея завершилась и Python 3.11 вышел в релиз. Предлагаем заварить чайку и похоливарить на тему стилей, принципов и нотаций именования переменных. На связи Evrone, мы рады говорить с вами на одном языке.

Ключевые изменения

Ещё не успел остыть свежеиспечённый релиз Python, как в чатах разработчиков посыпались шутки о том, что следующая версия должна называться Python NT Workstation. Но шутки-шутками, а Python 3.11 for Workgroups получился весьма интересным. Путь к релизу был тернистым и включал в себя 5 beta-версий и сдвиг срока релиза. Благо всё это позади, и мы можем взглянуть на результат.

Эталонный интерпретатор CPython стал быстрее. Прирост составил от 10% до 60% по сравнению с предыдущей версией 3.10. В качестве средней цифры разработчики называют 25%. Публичные результаты бенчмарков опубликованы на Github. В качестве небольшого спойлера — там же вы найдёте и результаты альфа-версии 3.12.0a0.

Добавили группировку и одновременное использование нескольких несвязанных исключений. Реализовано это с помощью типов ExceptionGroup и BaseExceptionGroup. Оператор except также получил синтаксис, позволяющий управлять этими группами. Вдобавок исключения теперь можно снабжать заметками через метод add_note().

Стандартная библиотека пополнилась модулем для парсинга TOML-файлов tomllib. Этот формат появился давно, ещё 9 лет назад, и с тех пор хорошо зарекомендовал себя для хранения настроек в различных приложениях. Разумеется, это не единственные изменения, но наиболее значимые. Познакомиться с оставшимися можно в официальной документации.

EAFP против LBYL

Зубодробительные аббревиатуры наше всё. Но если WYSIWYG знает каждый, то аббревиатуры EAFP и LBYL многие слышат впервые. Первое переводится, как Easier to Ask for Forgiveness than Permission (проще просить прощения, чем разрешения). Применительно к программированию этот принцип означает, что можно писать любой код и ожидать, что он будет работать как положено. Если на каком-то этапе возникает исключение, то его нужно обработать соответствующим образом.

Полной противоположностью EAFP является принцип LBYL — Look Before You Leap (посмотри, прежде чем прыгать). Используя этот принцип, следует вначале удостовериться, что решение сработает и лишь потом писать код. Такой подход более применим для других языков программирования, таких как C/C++, где возникновение исключения — ситуация действительно исключительная. Для Python она таковой не будет.

Прекрасная демонстрация есть на StackOverflow.

EAFP:

try: x = my_dict["key"] 
    except KeyError: 
    # handle missing key

Мы пробуем присвоить переменной значение ключа, выполнив поиск в словаре. Если что-то пошло не так — выбрасываем исключение. Ключ ищется только один раз.

LBYL:

if "key" in my_dict: 
    x = my_dict["key"] 
else: 
    # handle missing key

А тут получается мы ищем ключ дважды. Первый раз, чтобы сработало условие и второй раз для присвоения переменной. Вариант рабочий, но менее читабельный.

Если начать сравнивать оба этих принципа, то может возникнуть ощущение, что EAFP может обойтись «слишком дорого» и снизит производительность. Отчасти это правда, но каждая новая реализация интерпретатора «снижает стоимость» использования исключений.

В сухом остатке можно сделать простой вывод о том, что EAFP отлично подходит для Python. Разумеется, это не исключает того, что выбор остаётся исключительно за разработчиком.

Нотации именования

В холиварах про имена переменных отметилось не одно поколение разработчиков. Все хотят единое правило, но каждый — своё. Давайте взглянем на наиболее популярные нотации.

• Pascal case требует имена переменных начинать с заглавной буквы, например, Name. Если имя содержит несколько слов, то все они должны начинаться с заглавной буквы. Пример — FirstName.
• Camel case (верблюжья нотация) очень похожа на Pascal case, но есть одно кардинальное отличие. Односложные имена начинаются со строчной буквы, например, name. Если имя содержит несколько слов, то первая буква строчная, а все последующие заглавные. Пример — firstName.
• Snake case (змеиная нотация). Все имена начинаются со строчных букв. В качестве разделителя используется нижний пробел. Пример — first_name.
• Kebab case (шашлычная нотация) такая же, как и Snake case, но в качестве разделителя используется дефис. Пример — first-name.
• Hungarian notation (венгерская нотация) отличается от всех. Имя любой переменной предваряется заранее определёнными префиксами. Строгих правил у этой нотации нет — префикс может быть из одного или нескольких символов. При этом она может мимикрировать под другие нотации. Примеры — pFirstName, pfirst_name, pfirst-name.

Это наиболее часто употребляемые нотации, в жизни их гораздо больше. И несмотря на то, что можно выбрать любую, для каждого языка предусмотрена предпочтительная нотация.

В Python — это Snake Case для функций и переменных, а также Pascal Case для классов, что зафиксировано в PEP8. Это руководство по стилю позволяет избежать множества неприятных ситуаций и рекомендуется к соблюдению авторами языка.

Интересно посмотреть

Пропустили наш предыдущий Python-митап? Не беда! Все доклады есть на нашем YouTube-канале в 4K.

Теперь следить за митапами Evrone стало удобнее. В Telegram-канале Evrone meetups мы выкладываем анонсы с подробными описаниями докладов, а также студийные записи после мероприятий. А ещё у нас можно выступить, мы поможем оформить вашу экспертизу в яркое выступление. Подписывайтесь и пишите @andrew_aquariuss, чтобы узнать подробности.

Вакансии