LINUX.ORG.RU

Python 3.13

 , ,


1

5

После года разработки вышла новая стабильная версия интерпретируемого языка программирования Python 3.13. Релиз включает изменения в собственно языке и его стандартной библиотеке. К важнейшим изменениям относятся использование нового интерактивного интерпретатора по умолчанию, экспериментальная поддержка работы в режиме free-threaded (т. е. с отключением global interpreter lock) (PEP 703), и JIT-компилятор (PEP 744).

С этого релиза осуществлён переход на новый цикл релизов Python (Annual Release Cycle for Python, PEP 602), в связи со стремлением расширить период «полной поддержки» новых выпусков:

  • Python 3.9–3.12 имеют полтора года полной поддержки, за ними следует три с половиной года исправления брешей в безопасности.
  • Python 3.13 и более поздние релизы будут иметь два года полной поддержки и три года исправлений уязвимостей.

Продолжается работа по усовершенствованию сообщений об ошибках. Теперь traceback’и по умолчанию подсвечиваются цветом. Встроенная функция locals() теперь имеет определённую семантику для изменения возвращаемого меппинга (PEP 667), а параметры типов (typing.TypeVar, typing.ParamSpec, typing.TypeVarTuple) поддерживают значения по умолчанию (PEP 696).

Изменения стандартной библиотеки включают удаление устаревших API и модулей (aifc, audioop, cgi, cgitb, chunk, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu и xdrlib), а также привычные улучшения в области дружелюбия к пользователю и корректности. Несколько модулей исключены из поставки в связи с объявлением их устаревшими в Python 3.11 (PEP 594), в том числе инструмент и библиотека 2to3.

Из улучшений безопасности стоит отметить, что ssl.create_default_context() устанавливает флагами по умолчанию ssl.VERIFY_X509_PARTIAL_CHAIN и ssl.VERIFY_X509_STRICT.

Добавлена поддержка платформ: Apple iOS и Android теперь официально поддерживаемые платформы (tier 3) (PEP 730, 738). wasm32-wasi поддерживается на уровне tier 2, прекращена официальная поддержка wasm32-emscripten.

Для более основательного ознакомления с нововведениями релиза, обращайтесь к официальной документации (по библиотеке, по языку). Руководствуйтесь статьей «Переход на Python 3.13» для обновления своих проектов на новую версию языка. Также см. changelog.

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



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 7)

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

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

Отлаживается твой MPI

https://stackoverflow.com/questions/57519129/how-to-run-python-script-with-mpi4py-using-mpiexec-from-within-pycharm

Они ж эти отладчики как клиент-сервер работают, а там лишь общая сеть была

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

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

Нет там входа на узел. Скрипт запускает шедулер из общей очереди, и делает он это когда то потом, ночью, как получится. Есть доступ к выхлопу кода, а так даже сети с узла наружу нет.

Я же говорю, Вы свой личный опыт пытаетесь обобщить на все случаи жизни. Всё тут дураки сидят, один Вы познали дзен правильной отладки…

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

кста если кластер эмульнуть на локалной сети с обычными десктопами - чисто как лаб окружение хоть какое то ускорение возможно (при сохранение обычного юзер экспиринса у десктоп-пользователей) - чисто поиграться с dusk и прочими массово-распределёнными с python-интерфейсом

чисто на обычной локалке это кроме учебного опыта какой выхлоп?

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

От решаемых задач зависит. У нас даже как то собирали для заказчика кластер из 24х десктопных корпусов и считали на нем вполне актуальные вещи.

Там проблема с надёжностью вылезает. А так вполне.

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

Pandas, Numpy, Tensorflow, Pytorch, Pycuda, Sklearn, Seaborn - без них приличный человек который занимается чуть большим чем сует указатель куда не надо, как без рук.

Numpy, Sklearn – это который ///Numpy contains a powerful N-dimensional array object, sophisticated (broadcasting) functions, tools for integrating C/C++ and Fortran code, and useful linear algebra, Fourier transform, and random number capabilities?

Pandas, Sklearn – это которые в зависимостях просят binutils и gcc?

Pycuda – Speed. PyCUDA’s base layer is written in C++, so all the niceties above are virtually free.

Seaborn – который хочет llvm?

Т.е. пионисты как без рук без библиотек, написанных сователями указатель куда не надо? Так зачем тогда именно Питон?

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

Датасасаенс - это не про программирование на питон. Датасаентист или нейронщик - это не программист. Это как тестеровщик. Питон может использовать сишные либы как могут NodeJS, PHP, Perl, Java и тп… Скриптовые языки были придуманы для веба, где работа с сокетами и строками не грузит CPU, а вот для CPU-bound он уже не подходит мешает сборщик мусора, неэффективны структуты с динамическим выделением памяти и тд и тп… Питон выбран лишь из-за простоты синтаксиса м утинной типизации.

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

Поставил дизлайк видео. Оно начинается прямо со сравнения C++ и Java с Python. Он на одну ступень ставит наши православные кресты с интепретируемой жабой… А дальше пошла канитель про matlab и прочие ненужновещи типа математики, суперкомпьютеры для тру-программистов

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

Т.е. пионисты как без рук без библиотек, написанных сователями указатель куда не надо? Так зачем тогда именно Питон?

Попробую раскрыть свою мысль если вы способны воспринимать. Куча языков написано на С, да тот же PHP, Perl и тд.

Во-первых, так исторически сложилось, что когда эти языки создавались С был основным языком на котором писались операционные системы общего назначения. Логично было писать на нем под эти самые системы.

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

Языки более высокого уровня, заполняя эту пустоту, добавляют слой абстракции в виде себя позволяя разрабатывать в десятки раз быстрее. Такие языки грубо говоря - обертки над набором С-библиотек и функций, долго и мучительно написанных и отлаженных, с кровью и потом, но один раз.

Дальше, используя соглашения о взаимодействии этого языка (синтаксис) можно гораздо быстрее разрабатывать программу. Даже используя готовые C библиотеки, но оперируя ими на С все равно в подавляющем большинстве случаев разработка будет гораздо медленнее чем на языке более высокого уровня абстракции.

Да, сам язык при этом будет медленнее С, но это палка о двух концах: с одного скорость выполнения программы, с другого скорость разработки программы. Разные языки высокого уровня позволяют ухватиться за эту палку в разных местах от краев. Таким образом можно подбирать язык (инструмент) под задачу.

Поэтому программистов которые пытаются на С решать вообще все задачи (т.к. других языков не знают), тратя огромное количество времени на программу которая вполне может работать в 2 раза медленнее, но быть созданной в 20 раз быстрее, я называю сователями указателей куда не надо.

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

основная реальная причина почему не фсё на Си

не в Си как таковом

а в сложность программисту не срезать углы через протечку абстракции

использование нескольких языков снижает возможность мигая битиками получить полное ub

ну и буккипинга меньше там где сам язык позволяет как либо «перегружать» синтаксические конструкции в том или ином виде в нужное поведение

т.е сейчас дешевле иметь ограниченые инструменты для «недисциплинированных» программистов чем иметь гуру самоконтроля переключением малого количества битов получающего от сверхложной системы произвольное желаемое на перёд поведение :)

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

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

Причем в наше время продукт практически никогда не будет завершен и отлит в граните на года, он будет постоянно меняться тк меняются условия рынка. Скорость разработки это и скорость внесения изменений в уже созданное. А также важно ведь чтобы стоять на месте нужно бежать изо всех сил…

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

Это все не объясняет, как так вышло, что главным языком для перемножения матриц стал язык, лишенный массивов. Почему, например, R проиграл? Раз библиотеки все равно на низкоуровневых языках.

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

Это все не объясняет, как так вышло, что главным языком для перемножения матриц стал язык, лишенный массивов.

Как раз объясняет, numpy использует С. Этому пакету почти 30 лет. Другое быстрое перемножение матриц - на видеокартах, там опять используется C (NVIDIA CUDA). Питон просто удобный клей для этого всего.

Почему, например, R проиграл?

R не проиграл, а ушел в стат. вычисления. Поэтому анаконда при создании нового окружения позволяет указывать версию питона и R. И то и другое используется. Точно также не проиграл MATLAB, а занял свою нишу.

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

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

Вполне. Torch, например, изначально с Lua делали, это потом уже появился PyTorch.

Но есть нюанс: в Lua из коробки нет классов (есть только прототипное ООП на метатаблицах) и нет вообще никаких «батареек» (всё есть в сторонних модулях, но их нужно ставить, и пакетного менеджера из коробки нет), что, естественно, не способствует популяризации в качестве ЯП общего назначения.

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

Но главная цель этого всего (использование языков более высоких абстракций и использование джунов в продакшне) - увеличение скорости разработки продукта

А также уменьшение количества ошибок (потом что люди ошибаются всегда, но особенно часто, когда у них горят дедлайны). А также упрощение отладки. А также перекладывание работы, которую может сделать машина (управление временем жизни объектов и т.д.), с человека на эту самую машину (хотя в капиталистическом обществе о людях заботятся в последнюю очередь).

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

Вот и как юзер и как разработчик не знаю ни одного проекта на 2 питоне который был жив когда он сдох. Это только у совсем странных личностей он нужен, как фортран примерно. Кто тут на ЛОР-е ноет про второй питон - пара учёных из НИИ и универов у продуктов которых нет пользователей, а сам ЯП им нужен только как продвинутый калькулятор для научных рассчётов (а каких-то 10-20 лет назад они (не конкретно эти люди с ЛОР-а а их предшественники и коллеги) так же ныли сначала про фортран, потом про делфи, как они ныли про кобол я не застал). Ну и пара челиков с легаси кодом и дикой нехваткой финансирования страдают, остальным норм всё.

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

А также уменьшение количества ошибок

А также упрощение отладки.

А также перекладывание работы, которую может сделать машина (управление временем жизни объектов и т.д.), с человека на эту самую машину

А также это все напрямую входит в то что я описал как «скорость разработки».

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

Предлагаю здесь обрамлять слово «ученые» в кавычки т.к. те «ученые» что напыщенно били себя пяткой в грудь и апеллировали к авторитету оказались обычными околонаучными балаболами опростоволосившимися на обсуждении физики школьного уровня. Дважды. А так хорошо начинали…

Поэтому и все их заявления про второй питон да и вообще их мнение не имеет никакого веса. Закопали его и хорошо.

Obezyan
()

фигасе вы разошлись. пацаны фсё нормально я сконвертировал строчки, тред можно закрывать. до гнома с его 1000+ всё равно не доплюнем

alt-tab-let ★★
()
Ответ на: комментарий от alt-tab-let

фигасе вы разошлись. пацаны фсё нормально я сконвертировал строчки, тред можно закрывать.

А все уже, все, а надо было раньше… Через пяток постов свернем на лишп чтобы внесли Лавсанчика и выжмем еще соточку-другую постов.

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

данные хранить, а не классы. Бич вариант, если данные небольшие - сериализация в жсон. Если данных много - можно какой протобаф заюзать сверху с гзипом. Если лень тянуть зависимости, можно байтики ручками писать с полями, но такое себе, как пример:

[size of element identifier, short][element identifier, bytes][fields count, long][size of field identifier, short][field identifier, bytes][size of field value, short][field value, bytes]

обычно научные пакеты пишут такое ^ сами. Некоторые, пишут текстовые таблицы, удобно читать глазками, а вот парсить, обычно, не очень

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

ну, что-то всё же есть

да, забываю про collections постоянно

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

Интеллектуально такого рода люди часто стоят очень высоко

похвала algol-68 в инкарнации пьЯнота дорогого стоит

зы. перегрузка d| для отладочной трассы в отладчике середины 90ых от чемпиона icpc , перегрузка / для пакетов в пакетах

аг ага - не наброс - «мне просто спросить»

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

в Lua из коробки нет классов (есть только прототипное ООП на метатаблицах) и нет вообще никаких «батареек» (всё есть в сторонних модулях, но их нужно ставить, и пакетного менеджера из коробки нет), что, естественно, не способствует популяризации в качестве ЯП общего назначения.

В Lua ещё с целочисленными данными неудобно работать. И автодополнения нет :) И тоже совместимость ломают.

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

Мне одно интересно, зачем разработчикам вообще связываться с Питоном для новых проектов в связи вот с этими «бесконечными версиями Питона»?

А что вместо него осталось?

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

При заработке в 150тр. в месяц, три дня работы разработчика это между 20 и 30тр.

На фоне годового бюджета – крохи.

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

не знаю ни одного проекта на 2 питоне который был жив когда он сдох

Mercurial :) И выросшие вокруг него CMS и PMS.

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

И автодополнения нет :)

Зависит от IDE

И тоже совместимость ломают.

А тут всё совсем плохо. Значительная часть сообщества осталась на 5.1 + некоторые фичи из 5.2, так как LuaJIT ничего более нового не умеет, а без LuaJIT не интересно. Другая часть ушла вперёд вместе с референсной реализацией.

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

Зависит от IDE

В интерпретаторе по умолчанию, который есть без всяких IDE. В линуксовом Питоне было страшно удобно – нажал Tab после переменной, и смотри список всех доступных полей и методов. В новой версии так стало можно и под оффтопиком.

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

В интерпретаторе по умолчанию, который есть без всяких IDE

Вот что нашлось: https://github.com/dpapavas/luaprompt

В интерпретаторе по умолчанию такого не будет никогда, так как минимализм.

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

в Lua из коробки нет классов (есть только прототипное ООП на метатаблицах) и нет вообще никаких «батареек»

Всё это есть в Pluto 0.9.2. Скоро выйдет 0.10.

dataman ★★★★★
()

Изменения стандартной библиотеки включают удаление устаревших API и модулей (aifc, audioop, cgi, cgitb, chunk, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu и xdrlib), а также привычные улучшения в области дружелюбия к пользователю и корректности. Несколько модулей исключены из поставки в связи с объявлением их устаревшими в Python 3.11 (PEP 594), в том числе инструмент и библиотека 2to3.

А они после 3.10 что-то полезное реализуют вообще или только выпиливают всё, что под руку попадётся?

Да, мне не всё равно, это у меня один из основных рабочих инструментов.

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

Mercurial

Оно умерло лет 10 назад, куда раньше второго питона который тянули до недавнего времени. То что десяток челиков что-то туда контрибутят ни о чём не говорит. Главное что юзеров у меркуриала нет по факту.

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

@Shprot Юрок, ты что, на клована обиделся что-ли? Аахах. Ну извини, больше не буду)

stabilitron
()

Кто тут кричал что 2to3 переход прозрачен и тривиален? Час блин убил вот из за такого:

$ python2
>>> map(None, range(10), range(5))
[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, None), (6, None), (7, None), (8, None), (9, None)]
$ python3
>>> list(map(None, range(10), range(5)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable
>>> list(map(lambda i, j: (i, j), range(10), range(5)))
[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4)]

Сломать автору этих гениальных изменений обе руки, пусть учится ногами в носу ковырять…

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

Да получилось конечно, это все так или иначе решаемо. Жалко времени тратить на поиски таких вот глюков в уже давно отлаженном большом коде.

Не, ну ладно - сменили синтаксис. Ладно, ввели bytes. Ладно, поменяли функциональщину на полностью ленивую - хотя уже это вызывает бааальшие вопросы и с т.з. удобства и с т.з. скорости и главное с т.з. глюков при переходе 2to3 - постоянно об это бьюсь.

Но, йопрст, поменять поведение map - в py2.7 черным по белому написано было что map добивает None-ми недостающие последовательности, в отличии от zip! А в py3 - опаньки - map ведет себя как zip!!!111 Ну уроды же, слов цензурных нету…

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

odoo aka openerp очень долго переходило на 3-й питон, работало у многих, когда 2-й совсем сдох.

Shadow ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.