LINUX.ORG.RU

Arch Linux удалил Python 2 из репозиториев

 ,


0

3

Python 2 больше не будет поддерживаться разработчиками Arch Linux. Пользователи, у которых он уже установлен смогут его оставить, однако получать обновления безопасности они не будут. Остальные пользователи дистрибутива могут добавить себе сторонний репозиторий, в котором поддержка все еще осуществляется, либо использовать AUR.

Об окончании поддержки Python 2 было объявлено еще в январе 2020 года.

2 @AEP: действительно, проглядел конкретно.

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

★★★★

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

также они будут получать обновления безопасности

Неверно. Если пакет пропал из репозиториев, то у пользователей остается версия, которая у них была установлена на момент пропажи, и она не обновляется.

Более того, в оригинале имеем фразу:

but please be aware that there will be no security updates

AEP ★★★★★
()
Последнее исправление: AEP (всего исправлений: 1)

А как они qtwebengine собирают?

grem ★★★★★
()

Непонятно нахрена разработчики Python сломали совместимость, а не сделали её какой-нибудь слой.

Мне до сих пор иногда попадаются древние весьма нетривиальные скрипты под Python 2, которые просто так не перепишешь для третьей ветки. Раздражает эта херня.

В Java я взял JAR условно 2001 года, запустил на OpenJRE 19 и всё работает. А с Python должен заниматься пердолингом. Вот поэтому Java в Enterprise, Java это самые высокие зарпалаты, а Python это несерьёзно.

В Python 4 снова сломают к херам обратную совместимость и все будут страдать уже с тонной скриптов под Python 3?

EXL ★★★★★
()

Все, кто в курсе событий, что такое 2 и 3 в системе - сейчас радостно бухают по-черному

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

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

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

unDEFER ★★★★★
()

Не понял. Хм. Обычно это Шапка(Fedora) подобные штуки первыми делает …

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

Писал как раз когда Blender переходил со второй на третью версию. Долго плевался.

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

Я уже забыл, когда видел что-то, написанное на Python 2. И что при этом, нельзя переписать на Python 3. Всё-таки, разница между 2 и 3 не настолько большая, года до 2016 массовую миграцию сдерживало только то, что не все зависимости были под Py3.

Полную совместимость никто не держит. Попробуй C++ код из 2001 сейчас скомпилить. Да и запустить вряд ли получится.

И с твоим примером Java вряд ли всё так просто. Одна программа запустится, десять отвалятся по тем или иным причинам.

Не говоря уж о том, что очень сложно представить себе программу на любом языке из 2001, которая удовлетворяет условиям:

а) её никто с 2001 года не обновлял

б) она обладает хоть какой-то востребованностью

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

В Java я взял JAR условно 2001 года, запустил на OpenJRE 19 и всё работает

Брехня. Знаю несколько программ, которые под новыми jre не запустить.

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

Сишный код вообще часто может быть скомпилирован C++ компилятором. Но вы же не будете отрицать что C++ - новый язык?

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

У меня ощущение что они про Питон только слышали. Вспомнил первый же попавший проект :

https://bottlepy.org/docs/dev/

… Bottle supports Python 2.7 and Python 3. …

Есть еденицы что из анатации переменных делают > 3.6

Но если копать глубже это чисто их прикол, мол нет поддержи 2 и не фига.

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

Вот тут я не согласен, все таки ОО и не ОО дают большую разницу.

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

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

С большим проектом, придётся повозиться, конечно.

Но и с C++ всё не так просто. Я сейчас работаю над большим C++ проектом. В нём регулярно что-то, что компилилось старыми компиляторами, перестаёт компилироваться новыми.

С Java, к счастью, почти не сталкиваюсь. Но уверен, что и там всё совсем не так просто.

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

У Java несовместимостей тоже полно. Что было написано под 6, 8 или 11, на более новых имеет шанс крашиться. И так с каждой LTS версией.

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

Попробуй C++ код из 2001 сейчас скомпилить.

Внезапно скомпилится и будет работать, например:

https://github.com/heliocastro/qt1
https://github.com/heliocastro/qt2
https://github.com/heliocastro/kde2

А уж если про C говорить то там и из 80-ых скомпилится. Но какие-то минимальные правки будут точно нужны, или к примеру тот же -fcommon, потому что компиляторы стали строже со временем. Но это нативщина. В Java и Python это всё гораздо проще, учитывая байткод.

И с твоим примером Java вряд ли всё так просто. Одна программа запустится, десять отвалятся по тем или иным причинам.

Большинство запустится. Java, к счастью, славится одной из лучшей обратной совместимостью.

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

Изменились какие-то нюансы, которые можно узнать и исправить за пару часов.

Причем если не выеживаться, то сейчас пихая всякие import future можно писать чтобы и в 2-ке тоже работало.

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

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

Про то, как там в Java, не знаю, и слава Богу! Неужели действительно есть необходимость постоянно гонять какие-то проекты из 2001, к исходникам которых нет доступа, и которые с 2001 года не менялись?.. Такие случаи на всей Земле, думаю, можно по пальцам одной руки пересчитать.

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

Брехня. Знаю несколько программ, которые под новыми jre не запустить.

Приведи названия этих программ. Вот мой пример достаточно сложной программы-эмулятора на Java, которая имеет GUI-лаунчер, вывод графики и звука:

https://www.zophar.net/ivision/bliss.html

Сделана в 2001 году, 21 год назад.

Запускается сегодня на современной JRE и работает отлично:

https://0x0.st/oWT4.png

Уровень поддержки обратной совместимости недостижимый не то что для Python, но и для всех Linux-дистрибутивов в целом.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)

Опять бота для перепоста новостей с опеннета подрубили?

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

Я правда давно с этой бедой столкнулся. Меня просто задело, что я только написал код для Python 2 и мне уже его приходится переделывать, из-за выхода новой версии Blender.

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

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

Попробуй C++ код из 2001 сейчас скомпилить

Это шутка?

Корректный код даже из 90 будет скомпилирован новым компилятором.

Предыдущие стандарты поддерживаются компиляторами.

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)

Скатертью дорога Питону Второму. Плакать не буду.

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

Билиотеки где-то наверное изменились. Но для меня, как человека, постоянно пишущего на Python, не было проблем портировать. Где-то проще, где-то сложнее, но в целом несложно.

Для человека, который знает пыхтон по верхам, вероятно, могут возникнуть сложности… Сочувствую, но в целом жизнь - боль и без того. Вон в соседней теме PHPшники пишут, что у них несовместимые переходы за последние 10 лет уже 3-4 раза случались.

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

Увы, я не спец по C++, только учусь. У меня есть код, который не компилится, но в пятницу ночью я уже не полезу смотреть и разбираться почему… Если до понедельника сохраню запал, то постараюсь разобраться…

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

Вон в соседней теме PHPшники пишут, что у них несовместимые переходы за последние 10 лет уже 3-4 раза случались.

Да? Я что-то пропустил. Вообще без проблем обновил свой код уже не помню с какой на какую версию через много лет.

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

Неужели действительно есть необходимость постоянно гонять какие-то проекты из 2001

Пример из 2001 года это просто пример из мира Java. А с Python всё гораздо смешнее, учитывая что одни из самых популярных проектов на Python – Mercurial и Ansible с таким скрипом переводили на Python 3, что первый аж издох по пути, наполнив IT-сообщество пёрлами вроде таких: Ценой перевода Mercurial на Python 3 может стать шлейф непредвиденных ошибок и это не 2001 год, а 2020.

Да и знаешь ли сегодня в тех же RHEL-based дистрибутивах поставляются аж целых три версии этого Python из коробки: 3.7 системный для dnf, 2.7 для легаси и дефолтный новый из реп для твоих проектов – форменная помойка из трёх практически одинаковых наборов файлов стандартной библиотеки Python и чудовищный bad-practice. А всё из-за слома обратной совместимости.

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

Обратная совместимость в пределах мажорных версий не сломана.

Почему тогда в enterprise-дистре инженеры Red Hat зафиксировались на одной из минорной версии Python 3 для системных компонентов?

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

Непонятно нахрена разработчики Python сломали совместимость, а не сделали её какой-нибудь слой.

Гномеры покусали.

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

Полную совместимость никто не держит. Попробуй C++ код из 2001 сейчас скомпилить.

Даже с опцией -std=c++98 ?

Да и запустить вряд ли получится.

Из-за разниц с некоторыми библиотеками может конечно засада выйти.

Но в целом, мне кажется, что с обратной совместимостью в C и C++ все очень хорошо. У Perl тоже высокая совместимость, причем Perl 6 все же додумались переименовать в Raku

а) её никто с 2001 года не обновлял

б) она обладает хоть какой-то востребованностью

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

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

А в разных мажорных версиях её и быть не должно.

Если это язык программирования, вышедший из экспериментальной стадии и применяемый в продакшене, обратная совместимость, по-хорошему должна быть всегда. У gcc/g++ есть опции для компилятора, чтобы скомпилировать код из 90-х и даже 80-х. Если решили отказаться совсем от совместимости, лучше язык тогда переименовать, как это сделали в Perl --> Raku

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

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

Я так не думаю.

У gcc/g++ есть опции для компилятора, чтобы скомпилировать код из 90-х и даже 80-х.

Просто и Си, и Си++ не очень меняются. И сами по себе тащат в себе кучу всего устаревшего.

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

Почему тогда в enterprise-дистре инженеры Red Hat зафиксировались на одной из минорной версии Python 3 для системных компонентов?

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

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

Ну это не нарочно было. А сломали от косяков.

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

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

Я так не думаю.

Я объясню. Питон 3 хоронил Питон 2. А Раку Пёрл хоронит? Смысл в том, что Питон 3 в итоге приводил к отказу от Питона 2. А новое имя – новый язык, при это отказ от поддержки старого не означает.

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

а) её никто с 2001 года не обновлял

б) она обладает хоть какой-то востребованностью

Ты не поверишь, но это большая часть компьютерных игр. Да и во многом софта в принципе.

Зачем переписывать и патчить софт, если он работает и делает то что нужно? Потому что очередному лялексоеду вперлось всё сломать? Вот поэтому линукс на десктопах и подсасывает.

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

Да где? Всего 2 :)

Какие такие 2?

Питон 3.6 не совместим с Питон 3.7, тот с 3.8, потом 3.9 и так далее.

Это НЕ однократная проблема. Это теперь так будет всегда!

Питонизм Линукса это как паразиты, которые пожирают растения. Этого языка не должно было быть в природе.

Это помимо того факта, что Питон это тормоз.

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

Питон 3.6 не совместим с Питон 3.7, тот с 3.8, потом 3.9 и так далее.

У меня один и тот же код работает на 3.6 и 3.9.

Это помимо того факта, что Питон это тормоз.

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

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

Питонизм Линукса это как паразиты, которые пожирают растения. Этого языка не должно было быть в природе.

Воистину так.

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

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

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

ЛОЛШТО? 95% кода выглядят абсолютно одинаково, что в Py2, что в Py3.

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

Есть сравнительно крупный проект на py2? Замечательно, но из py3 его невозможно импортить примерно никак, только переписывать. Официально предлагали переписывать на six, но намного проще переписывать сразу на любой нормальный язык (да хоть на rust) и использовать как модуль хоть из py2, хоть из py3 (и в перспективе выкинуть питоны из проекта). Когда модуль на условных сях проще сделать кросспитоновым между py2 и py3 — это показывает насколько фейлом был переход между py2 и py3.

Питон непригоден для рефакторинга, а миграция с py2 на py3 — именно рефакторинг.

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

У меня один и тот же код работает на 3.6 и 3.9.

Непитоновые модули (хотя бы cuda) ни разу не работают между версиями. В тех же вебах половина зависимостей, внезапно, не на питоне.

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

У меня один и тот же код работает на 3.6 и 3.9.

А у Red Hat – не работает. Потому они для dnf тянут отдельный Python фиксированной версии.

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

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

У C? Вообще нет такого, единичные случаи зависящие от библиотек. Даже допотопный K&R синтаксис вида:

main(argc, argv)
int argc;
char *argv[];
{ return 0; }

До сих пор жуётся современным компилятором. Единственное значимое изменение в GCC, которое ломает сборку кучи древних проектов, это https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678, которое можно нивелировать флажком -fcommon.

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

Непонятно нахрена разработчики Python сломали совместимость, а не сделали её какой-нибудь слой.

Ничего, сейчас и у Java будет весело когда все будут переходить с javax на jakarta (Spring Boot 3 и все дела) ;) ;) ;)

X-Pilot ★★★★★
()
Последнее исправление: X-Pilot (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.