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

А где легко рефакторить? И что изначально не говно? Даже если разработчики питона завтра скажут что питон говно и его надо выкинуть, им сразу перестанут пользоваться те миллионы, которые его знают? Что взамен? Что взамен привычных библиотек? В чём заключается уродство? Не пост, а целый кладезь вопросов.

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

Я не копался в содержимом конкретно питона, но судя по тому, что, например, в редхатовском ceph’е есть бэкпорты сквозь две мажорных версии из апстрима (в 14.2.х бэкпортнули функционал из ветки 16.х.х), выбор версий у редхата происходит по принципу «на момент фриза эта версия последняя, сюда и будем патчить все подряд».

Firefox это не проект на C++, а проект на Clang/Gcc?

Может доктора поискать?

А что у тебя GCC делает?

Ты написал, что Firefox собирается только Clang 14, перечитай свой пост.

Если это так, то это проект на Clang, а не на С++.

Всё верно, если проект собирается только на одной версии компилятора, то проект написан на Clang, где ошибка в моих рассуждениях?

Если бы проект был написан на C++, то его можно было бы собрать как минимум тем же GCC, разве не так?

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

Ты же сам мне пару дней назад писал, что то что из гсс не удалили auto_ptr - это баг и надо его зарепортить.

Ну а так, вот тебе корректный код из 2000х: auto int foo = 0;. Компиляй

Ты же сам мне пару дней назад писал, что то что из гсс не удалили auto_ptr - это баг и надо его зарепортить.

Да, в новых версиях стандарта его не должно быть.

Вот примерно как нужно сделать авторам gcc с auto_ptr.

#if _HAS_AUTO_PTR_ETC
// тут весь код определяющий auto_ptr
// макрос _HAS_AUTO_PTR_ETC устанавливается в зависимости от стандарта и также других ключей компилятора
#endif

Но в старых версиях он есть.

Вот скомпилировал твой пример, флаг -std=c++98 в помощь: https://gcc.godbolt.org/z/c4nbWzY9h

Если так смотреть, то да

С++98, С++11, С++14, С++17, С++20, С++23 это всё разные языки и код корректный для одного стандарта может не скомпилироваться в более новом, то есть обратной совместимости на уровне исходников нет.

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

В чём заключается уродство

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

Вот сообщение при сборке media-gfx/openvdb:

#error – unsupported GNU version! gcc versions later than 11 are not supported!

Ты написал, что Firefox собирается только Clang 14, перечитай свой пост.

Сэр! Вы идиот! Вы не знаете про компьютеры ровным счётом ничего. Вы пишите ЕРЕСЬ!

Firefox это проект написанный НА C++ и RUST.

Речь изначальна шла о том, что БОЛЕЕ НОВЫЕ компиляторы НЕ поддерживаются определёнными версиями разных программ или библиотек.

Вам и другому танкисту был приведён пример этого.

Clang или GCC это просто разные реализации компилятора С++. В некоторых случаях лучше использовать один, в других - другой.

На самом деле используют НЕ компилятор, а Toolchain. Т.е. набор компонентов для сборки программ. Этот набор взаимосвязан друг с другом. Т.е. все программы из набора должны работать вместе. В итоге есть toolchain, который базируется на clang или точнее llvm, а есть который на gcc и так далее.

Но основная суть именно в том, что с помощью последней вышедшей версией почти любого компилятора НЕЛЬЗЯ собрать ВСЁ что угодно.

Теоретический голый текст на C++ написанный в стиле С, наверно можно собрать любым компилятором, но таких случае в практике НЕТ. Меняется и сам язык и библиотеки.

Тот же RUST эту проблему осознал и по этому создал такую вещь как редакция компилятора по мимо версии. В рамках одной редакции код написанный для нее будет компилироваться любой версией компилятора. Этого НЕТ в случае C++.

Читать здесь: https://doc.rust-lang.org/edition-guide/editions/index.html

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

то проект написан на Clang, где ошибка в моих рассуждениях?

Нет и еще раз НЕТ. Ошибка в рассуждениях в том, что речь была о КОНКРЕТНОЙ версии clang!!! НЕ о самом clang.

Build system cmake для firefox проверяет используете ли Вы версию 14 или нет. И если нет, то выдает ошибку! Т.е. нельзя использовать версию 15 или 16. Иногда можно использовать версию 13 или ниже. Иногда нельзя. Т.е. есть ограничения И сверху И снизу!

И так ВЕЗДЕ и во ВСЁМ!!!

Если Вы используете GCC, то там другие ограничения версий!!! Номера версий другие! Например это скорее будет версия 11.3 Хотя давно есть 12ая версия GCC.

проблема именно с FIREFOX заключается в том, что вы в любом!!! случае используете LLVM, потому что вы используете RUST, который НЕ может без LLVM. Соответственно и RUST должен быть собран с помощью LLVM 14. В итоге зависимость от версии GCC теряется где-то там в глубине. Компилируя FIREFOX И с помощью GCC тоже Вы просто добавляете еще одну зависимость и еще одно ограничение.

И это все очень и очень плохо. Но это так есть и с этим сделать ничего нельзя.

И по этому RUST будет побеждать. У него нет этих проблем.

С++98, С++11, С++14, С++17, С++20, С++23 это всё разные языки и код корректный для одного стандарта может не скомпилироваться в более новом, то есть обратной совместимости на уровне исходников нет.

Именно! Об этом пытаются умалчивать. Именно что разные языки. И совместимости нет вообще никакой.

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

И если у Вас условно есть голый текст, который написан неизвестно для какой версии компилятора и версии стандарта, то Вы можете убить несколько дней, чтобы вообще ЭТО скомпилировать.

Это хроническая ошибка реализации C++.

В С++ основная проблема НЕ сам язык, а все что вокруг него. Тот же CMAKE и как оно все сделано вызывает тихий ужас!

Для сравнения CARGO это просто гениально. В итоге может быть RUST не сильно лучше как язык и почти никем не поддерживается, но писать на нем сильно проще. Геморроя в 10 раз меньше.

В С++ как раз повторяется та же ошибка питона, когда разные версии языка убивают друг друга.

В таком случае версия на которой написан код должен быть встроен в сам код. Потому как исключительно только автор может знать подо что он там чего писал. Но даже это по сути НЕ работает. Автор физически не может знать будет ли его код написанный под С++11 условно работать так же и под С++23. Он ничего не знает про будущие стандарты.

В итоге мы имеем часть кода написанного под C++11, а потом приходит Петя и пишет другую часть под C++23, потому как это уже происходит в 2025 году.

Это значит, что сам компилятор должен уметь конвертировать код из одного стандарта в другой. Иначе если программный продукт пишется 10-20 лет, то мы попадаем в капкан, когда C++11 уже не поддерживается новой версией компилятора, а C++30 ещё не поддерживается. Т.е. любо приходится замораживать версию компилятора специально для данной программы или вообще версию всей системы. Или каждый раз переписывать все заново.

Но об этом вообще никто не думает.

Вы просто не умеете его готовить)

Вопрос НЕ по адресу. Вы это расскажите компании NVIDIA, Mozilla и тысячам других.

Расскажите это автору питоновской оболочки под OpenCASCADE.

Лично «Я» как физическое лицо НЕ могу переписывать ВЕСЬ имеющийся код КАЖДЫЙ РАЗ, под новую конкретную версию Питона.

Если ВЫ можете, то почему ВЫ ещё не занялись этим?

P.S. У Вас ооочень странное мировоззрение. Есть Я и больше ничего и никого нет. Я могу по этой дороге ехать 160, значит все могут! Какого фига там поставили ограничение 80?

От этого лечится надо… Подумайте над этим.

Полумеры! Даёшь скорейший выпил тройки!

В чём заключается уродство?

Если возможно хотя бы частичное отсутствие интеллисенса - язык уродлив

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

А до этого что - получали что-ли? Питон-2 уже пару лет как не поддерживается разработчиками питона. Неужто арчевские майнтейнеры сами обновления безопасности для заброшенного языка клепали, а не просто тормозили пар лет на ровном месте?

То есть, брейнфак - идеальный язык?

Иначе если программный продукт пишется 10-20 лет, то мы попадаем в капкан, когда C++11 уже не поддерживается новой версией компилятора, а C++30 ещё не поддерживается. Т.е. любо приходится замораживать версию компилятора специально для данной программы или вообще версию всей системы. Или каждый раз переписывать все заново.

Но даже ещё не выпущенные gcc 13 и clang 16 поддерживают все версии С++.

В целом я понял, очередной раст сектант порвался и не показал ничего.

И где тут вызовы? Что в подсказках показывать?

Таблетки пропейте.

В рамках одной редакции код написанный для нее будет компилироваться любой версией компилятора.

Это, кстати, 4.2

А замена coroutine на asyncio это как раз серьезная поломка обратной совместимости. Благо код ранних 3х версий не так сильно распространён. Но утята, которые используют loop на старте до сих пор распространены.

Новая версия python2 есть в aur и он будет обновляться с патчами от gentoo.

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

Не удивлюсь когда выпустят Python 4 например без GIL, опять всё поломают

Если код завязан на GIL, место этого кода на помойке.

Код расширений завязан на GIL. Он не может не быть завязанным на GIL.

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

там дело не в отсутствии исходников, а в том, что го…но на java переписывать то еще удовольствие. «write once …» - это про java.

питухОн нинужОн!

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

С Common Lisp ты можешь взять код 80-х (не использующий проприетарные расширения) и он заработает на SBCL релизнутом месяц назад.

Это я к чему? К тому что причин почему Python - это несерьёзно чуть больше чем одна. :)

им сразу перестанут пользоваться те миллионы, которые его знают? Что взамен?

Взамен у них сразу появится время на школьные задания.

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

Да да, конечно ынтерпрайзно. Есть такие экземпляры, которые запускаются только на определённой сборке. Понты это все дешевые.

Это первые звоночки что-ли!

Странно и грустно что остались ещё моральные уроды смеющие требовать какой-то там совместимости для их неподдерживаемых py2 скриптов. А так-то всегда приятно когда безвозвратно отсекается очередной пласт легаси старья. Мои-то модули на PyPI питон ниже 3.9 уже не поддерживают.

КАЖДЫЙ РАЗ

14 лет прошло. Это даже не смешно

питухОн нинужОн!

точняк!

Держи пять бро!

Python 2 был объявлен deprecated настолько давно, что выросло уже поколение тех, кто никогда его не видел.

Python 3.0 был выпущен в 2008 году. 14 лет назад!

Последняя мажорная версия Python 2 вышла в 2010-м году. 12 лет назад!

Может хватит уже ныть - было просто дофига времени перейти на третий, тем более, что создатели сделали просто массу усилий для того, чтобы помочь в этом. Начиная с того, что разница между 2 и 3 не такая уж радикальная (как, например, в Perl 6, который похоронил Perl), заканчивая инструментами типа 2to3.

Паразиты никакие аргументы не принимают. Нет, ради них НИКОГДА НЕ ДОЛЖНЫ ломать совместимость, зато должны поддерживать их мусор БЕСПЛАТНО и БЕСКОНЕЧНО.

Интересно, а когда третий питон удалят нафиг из репозиториев?

Питон это жалкое поделие, Раст рулит!!!