LINUX.ORG.RU

Python 3.9.0

 , ,


2

4

Вышел новый стабильный релиз популярного языка программирования Python.

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

Python – стабильный и распространённый язык. Он используется во многих проектах и в различных качествах: как основной язык программирования или для создания расширений и интеграции приложений. Основные области применения: веб-разработка, машинное обучение и анализ данных, автоматизация и системное администрирование. В настоящий момент Python занимает третье место в рейтинге TIOBE.

Основные изменения:

Новый высокопроизводительный синтаксический анализатор на базе грамматик PEG.

В новой версии текущий парсер Python на основе грамматик LL(1)(КС-грамматика) заменён на новый высокопроизводительный и стабильный синтаксический анализатор на базе PEG (РВ-грамматика). Анализаторы для языков, представленных КС-грамматиками, такие как LR-анализаторы, требуют особого шага лексического анализа, который разбивает входные данные в соответствии с пробелами, пунктуацией и так далее. Это необходимо, так как эти анализаторы используют предварительный анализ для обработки некоторых КС-грамматик в линейное время. РВ-грамматики не требуют отдельного шага лексического анализа, а правила для него могут быть заложены вместе с другими правилами грамматики.

Новые операторы и функции

Во встроенный класс dict добавлены два новых оператора, | для слияния словарей и |= для обновления.

В класс str добавлены две новые функции: str.removeprefix(префикс) и str.removesuffix(суффикс).

Аннотация типа для встроенных коллекций

В этом релизе включена поддержка синтаксиса обощённых типов во всех стандартных коллекциях, доступных в настоящее время.

def read_blog_tags(tags: list[str]) -> None:
    for tag in tags:
        print("Tag Name", tag)

Другие изменения

  • PEP 573 Доступ к состоянию модуля с помощью методов расширения C

  • PEP 593 Гибкие функции и переменные аннотации

  • PEP 602 Python переходит на ежегодные стабильные релизы

  • PEP 614 Смягчающие грамматические ограничения на декораторы

  • PEP 615 Поддержка базы данных IANA по часовым поясам в стандартной библиотеке

  • BPO 38379 сборка мусора не блокируется на восстановленных объектах

  • BPO 38692 os.pidfd_open, для управления процессами без гонок и сигналов;

  • BPO 39926 поддержка Unicode обновлена до версии 13.0.0

  • BPO 1635741, при многократной инициализации Python в одном и том же процессе, больше не происходит утечка памяти

  • Коллекции Python (range, tuple, set, frozenset, list, dict) ускорены с помощью векторного вызова PEP 590

  • Некоторые модули Python (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, _functools, _json, _locale, operator, ресурс, time, _weakref) теперь используют многофазную инициализацию, как определено в PEP 489

  • Ряд стандартных модулей библиотек (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) теперь используют стабильный ABI, определенный PEP 384.

>>> Подробности

★★

Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

Если уж делаете простенький язычок, то делайте сразу с аннотациями. Потомучто ЯП это не только интерпретатор. Это еще и подсветка, language server, дебагер и прочие радости жизни.

У меня не интерпретатор, а транслятор в C++, со статической типизацией. Что-то типа Nim, но намного примитивнее. В общем-то, весь его смысл в примитивности и есть.

Вот тут Stodin DSL (комментарий) я экспериментировал с решетом Эратосфена. Грубый подсчёт лаконичности дал такие результаты по символам:

python 1419
stodin 2193
nim 2241
d 2298
rust 2460
go 2660
java 2855
c 2944

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

Возможно, проблема в том, что автор решений на других языках плохо эти языки знал.

А лучше возьмите готовый.

Для работы я и беру готовые. Свой пишу как хобби. Тут важен процесс, а не результат.

Kogrom ()
Ответ на: комментарий от Kogrom

Вот тут Stodin DSL (комментарий) я экспериментировал с решетом Эратосфена. Грубый подсчёт лаконичности дал такие результаты по символам:
python 1419

Как это? По ссылке лежит такое решение:

def primes(n):
    multiples = set()
    for i in range(2, n+1):
        if i not in multiples:
            yield i
            multiples.update(range(i*i, n+1, i))

print( list(primes(100)) )

Это 6 строк и, в лучшем случае, 200 символов. Откуда 1419?

anonymous ()
Ответ на: комментарий от Linfan

Ну не такой уж и единый

Вполне. У меня в паре проектов вообще границ нет. В одной папке переплетены фронт и сервер. Общие либы, общие типы, доменные сущности, конфиг. Затем сборщик точечно лепит из этого бандлы для браузера и сервера

Да и на практике просто обмазываются килограммами пакетов из npm

Странно упрекать в простоте распространения либ. Конечно не чета упоротому pip

anonymous ()
Ответ на: комментарий от anonymous

Вполне.

И шо, require() уже в браузере заработал? :)

В одной папке переплетены фронт и сервер.

И эти люди еще рассказывают что-то про говнокод…

Странно упрекать в простоте распространения либ.

Не в распространении дело, а в киллограмах зависимостей, наговнокоженных от души сопричастными.

Linfan ★★★★★ ()
Ответ на: комментарий от anonymous

Пусть даже там много ложных срабатываний. Всё равно, это — далеко не «не выставляют».

Там по большей части фуллстеки нужны. И не факт, что в бакенде по итогу будет нода.

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

И шо, require() уже в браузере заработал? :)

Придуриваешься? Или слово «сборщик» не разглядел?

И эти люди еще рассказывают что-то про говнокод

Обычный код. Говнокод это твоя поделка на питоне

Не в распространении дело, а в киллограмах зависимостей

Смотря что выбрать. Вариантов масса. Базовые вещи компактные (express, react). Дальше накручивай сколько твоей душе угодно

anonymous ()

PEP 585 – Type Hinting Generics In Standard Collections

Заживём, больше не нужно обмазываться лишними ипортами. Ещё бы Optional вынесли в __builtins__, было бы совсем хорошо. А может и вообще все типы из typing нужно вынести, это не здоровая тема, когда это уже де факто стандарт, все юзают аннотации, и каждый модуль начинается с from typing import ....

WitcherGeralt ★★ ()
Ответ на: комментарий от anonymous

Придуриваешься? Или слово «сборщик» не разглядел?

Ну вот потому и весь код в знаменитом паттерне «спагетти» :) Знаю, что у вас, джиэсеров «так принято», но сути это не меняет.

Говнокод это твоя поделка на питоне

Ожидаемая анонская аргументация в стиле «сам дурак». Чо в анонах то сидишь? Чтобы дурь твою не фиксировали? ;)

Linfan ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

При ширине в 120 символов, «места хватит всем» (с) Да и List и tp.List сильно не отличаются. При этом нет месива неймспесов. Импортировать модуль, а не классы/функции/переменные какбэ правило хорошего тона.

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

List и tp.List сильно не отличаются

4 символа против 7, 175%.

какбэ правило хорошего тона

какбэ

Ключевое слово. Модуля typing в принципе не должно было существовать, не хватало его импортировать ещё.

Ну, и так, к слову, раз уж заговорили об этом. У меня в коде from-import из стандартной библиотеки помимо тайпинга и дейттайма встречается в каких-то единичных случаях, но в целом есть правило так не делать. А вот в рамках приложения (не библиотечный код, там от случая к случаю) почти всегда импортируется как раз через from-import, причём относительный на вложенности >2. Код так куда чище получается, ибо приложения зачастую сложные, мнокомпонентные с большой вложенностью пакетов, так что имя модуля легко может иметь префикс в 2-4 имени пакетов, тут импорт всего модуля никакой смысловой нагрузки не понесёт.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 2)
Ответ на: комментарий от anonymous

Разработку веду через создание небольших программ. Упёрся в то, что для аскетичной плюсовой консоли ничего больше придумать не могу. Надо переходить в графику. Осваиваю SDL.

В идеале нужен не SDL, а что-то более продвинутое, типа FLTK. Но в SDL мне нравится то, что можно напрямую работать с диспетчером событий. В FLTK я не нашёл такой возможности. Соответственно, для FLTK надо вводить в язык делегаты (функции обратного вызова), что я делать пока не хочу, так как считаю, что они уродуют структуру программы.

Альтернативой было бы создание более продвинутой библиотеки для работы с консолью, типа ncurses, но это менее интересно и более трудозатратно.

Kogrom ()
Ответ на: комментарий от WitcherGeralt

Модуля typing в принципе не должно было существовать, не хватало его импортировать ещё.

Мало ли чего не должно было быть. Имеен ситуацию уже по факту.

Относительно import vs from… import стремиться нужно к первому, не забывая про второе - все от архитектуры зависит.

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

ну вот потому и весь код в знаменитом паттерне «спагетти» :)

Что ты несешь? Я тебе привел пример, что код для клиента и сервера действительно един, чему ты изволил усомниться несколькими каментами выше. И вместо того чтобы признать этол факт, ты начинаешь делать выводы о коже, который в глаза не видел, токсичный ты дед

Ожидаемая анонская аргументация в стиле «сам дурак»

Анон посмотрел на твой говнокод. Мало что на питоне, так еще и без хинтов. Говно одним словом

anonymous ()
Ответ на: комментарий от anonymous

Мало что на питоне, так еще и без хинтов.

Ты мало того что анон, но еще и дурачок :) Какие хинты в py2? Закончится портирование на py3, будут и аннотации. Ты же видимо не в курсе, что они появились только в py3.6

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от Linfan

Ты мало того что анон, но еще и дурачок :) Какие хинты в py2? Закончится портирование на py3, будут и аннотации. Ты же видимо не в курсе, что они появились только в py3.6

Я — другой анон, и не возражаю против отсутствия типов.

Но давайте будем честны: проверка типов для python2 есть
https://mypy.readthedocs.io/en/latest/python2.html#type-checking-python-2-code

anonymous ()
Ответ на: комментарий от anonymous

Но давайте будем честны: проверка типов для python2 есть

PEP’ы по хинтам и аннотациям - относительно недавняя фича (2015й). Код проекта существенно старше. И вводить новшество в py2 код бессмысленно, поскольку уже идет портирование на py3 со всеми этими фичами. Тем более, что в py2 это хинты в коментах. Пример уже портированного кода:

https://github.com/sk1project/uniconvertor/blob/py3/src/uc2/cms/libcms.py

Linfan ★★★★★ ()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от arcanis

Спарк и

pyspark ессно :)

так называемые разработчики на скале

вот именно, что так называемые. Могу сказать по крупному энтерпрайзу: питон используется в 1.5 раза чаще джавы и в 20 раз чаще скалы. Цифирь статистически достоверная, уровень тысячи реп.

Linfan ★★★★★ ()