LINUX.ORG.RU

Perl 5.44

 ,

Perl 5.44

1

4

После года разработки опубликован релиз новой стабильной ветки языка программирования Perl — 5.44. При подготовке нового выпуска было изменено около 270 тысяч строк кода (без документации и автоматически сгенерированного кода — 110 тысяч), изменения затронули 860 файлов, в разработке принял участие 71 разработчик.

Ветка 5.44 выпущена в соответствии с утверждённым тринадцать лет назад фиксированным графиком разработки, подразумевающим выпуск новых стабильных веток раз в год и корректирующих релизов — раз в три месяца. Примерно через месяц планируется выпустить первый корректирующий релиз Perl 5.44.1, в котором будут исправлены наиболее значительные ошибки, выявленные в процессе внедрения Perl 5.44.0. Одновременно с выходом Perl 5.44 прекращена поддержка ветки 5.40, для которой обновления могут быть выпущены в будущем только в случае выявления критических проблем с безопасностью. Начался процесс разработки экспериментальной ветки 5.45, на базе которой в первой половине 2027 года будет сформирован стабильный релиз Perl 5.46, если не будет принято решение перейти к нумерации 7.x.

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

  • Добавлена экспериментальная возможность использования именованных параметров в сигнатурах функций, определяющих перечень передаваемых в функцию переменных не в теле функции, а при её объявлении. Новая возможность позволяет передавать параметры не в строгом порядке следования, а в произвольном порядке с использованием пар ключ/значения и синтаксиса как при назначении элементов в хэшах:
    • старый синтаксис:
      sub f { my ($x, $y) = @_; ...}
      f(1, 2);
      
    • сигнатуры:
      sub f ($x, $y) { ... }
      f(1, 2);
      
    • сигнатуры с именованными параметрами:
      sub f (:$x, :$y) { ... }
      f(y => 2, x => 1);
      
  • Добавлена экспериментальная возможность использования алиасов (указателей на указатели) в циклах foreach с несколькими переменными. Реализованная возможность позволяет создавать алиас в цикле foreach при единовременном извлечением сразу нескольких значений в одной итерации цикла. Например, можно сформировать алиас для элемента хэша c массивом при переборе разом ключей и значений хэша:
    use v5.44;
    use feature qw( refaliasing declared_refs );
    my %hash = (
      one => [1],
      two => [2, 2],
    );
    foreach my ( $key, \@items ) ( %hash ) {
      say "The $key array contains: @items";
    }
    # До версии 5.44 потребовалось бы выполнять разыменование:
    foreach my ( $key, $var ) ( %hash ) {
      say "The $key array contains: @$var";
    }
    # Без экспериментальных  возможностей refaliasing и declared\_refs:
    foreach my $key (keys %hash) {
      say "The $key array contains: @{$hash{$key}}";
    }
    
  • В регулярных выражениях реализован экспериментальный режим ‘enhanced_xx’, позволяющий использовать модификатор /xx с классами символов в квадратных скобках ([a-zA-Z]) для их разделения на несколько строк или подстановки комментариев. Например, условие if ($text =~ m/\[a-zA-Z]/){ можно оформить так:
    if ($text =~ m/[
      a-z # строчные буквы
      A-Z # заглавные буквы
      ]/xx) {
    
  • В генераторе псевдослучайных чисел для получения энтропии задействован системный вызов getentropy() на системах с его поддержкой (Linux, BSD, macOS). На остальных системах для получения энтропии осуществляется чтение из устройства /dev/urandom или использование хэша от времени, идентификатора процесса и значения указателя.
  • Добавлена поддержка спецификации Unicode 17.0.
  • Обеспечено строгое соблюдение правил Unicode для имён идентификаторов и групп регулярных выражений, в которых теперь запрещено использовать около 160 Unicode-символов, ранее подпадавших под класс \w. Например, из действия класса \w, охватывающего все буквы, цифры и символ подчеркивания, выведены латинские буквы в кружках, которые напоминают реальные буквы, но ими не являются. Изменение поведения затрагивает только программы, использующие режим use utf8.
  • Устранены уязвимости, вызванные переполнениями буфера в функциях Perl_study_chunk (CVE-2026-8376, проявляется в 32-разрядных сборках) и S_measure_struct (CVE-2026-57432), а также переполнение 16-разрядного счётчика в Regex-движке (CVE-2026-13221), что может привести к неверному срабатыванию регулярного выражения.
  • Запрещён переход при помощи оператора goto на позиции внутри циклов и блочных конструкций. Данная возможность была объявлена устаревшей в 2010 году.
  • Проведены оптимизации производительности, ускорившие операции сложения, вычитания и умножения целых чисел, обработку сигнатур функций и заполнение хэшей из списков в формате ключ/значение с известными на этапе компиляции строковыми ключами.

>>> Источник: OpenNET

★★★★★

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

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

Ну да, так нагляднее в отличии от простых комментариев:

[a-z(?# строчные)A-Z(?# заглавные)]
dmitry237 ★★★★★
()

Полезный инструмент, но очень страшный, очень страшный..

MoldAndLimeHoney ★★★
()

«патологически эклектичный перечислитель мусора»

Gonzo ★★★★★
()

Лучше бы он не обновлялся, с учетом того, что даже при изменении минорной версии приходится всё пересобирать.
Наравне с boost и icu

Sylvia ★★★★★
()

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

zabbal ★★★☆☆
()

Обоже. Так и заикой можно стать.

yvv1 ★★
()

если не будет принято решение перейти к нумерации 7.x.

то есть возможно пальцы не закончатся?

imul ★★★★★
()

Perl жил,
Perl жив,
Perl будет жить!

Smacker ★★★★★
()
sub f (:$x, :$y) { ... }
f(y => 2, x => 1);

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

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

Могу (с малой вероятностью, скорее всего он имел в виду не это) предположить, что это про C extensions. Там нужно собирать строго с теми же флагами, с которыми был собран perl. Ну или про то, что ломают ABI/API. I dunno.

$ perl -V | grep 'config_args='
    config_args='-Dmksymlinks -Dusethreads -Duselargefiles -Dcc=x86_64-linux-gnu-gcc -Dcpp=x86_64-linux-gnu-cpp -Dld=x86_64-linux-gnu-gcc -Dccflags=-DDEBIAN -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/dummy/build/dir=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Dldflags= -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.40 -Darchlib=/usr/lib/x86_64-linux-gnu/perl/5.40 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/x86_64-linux-gnu/perl5/5.40 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.40.1 -Dsitearch=/usr/local/lib/x86_64-linux-gnu/perl/5.40.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -Ui_xlocale -Uversiononly -Ud_strlcpy -Ud_strlcat -DDEBUGGING=-g -Doptimize=-O2 -dEs -Duseshrplib -Dlibperl=libperl.so.5.40.1'
shdown ★★
()
Последнее исправление: shdown (всего исправлений: 2)

Настанет время и для Империума Человечества, но по прежнему будут программы на Perl.

Ну и всем рекомендую еще раз перечитать пару замечательных книг Damien Conwoy.

Nurmukh ★★★★
()
$ perl -v

This is perl 5, version 24, subversion 1 (v5.24.1) built for i686-linux
(with 1 registered patch, see perl -V for more detail)

Чот маловато релизов с 2017го.

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

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

У меня от perl зависят немногие вещи: mousepad-0.7.0, thunar-4.20.8, qt6-base-6.11.1, llvm19-19.1.7_4 и утилиты сборки.

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

ну да, что есть - то есть, это редкостная мозгодробилка для «мануальных» дистров/сборок

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

Зовите священника-экзорциста!

Сами справимся! 😁

P.S.

$> perl -v                                                                                                                                                           

This is perl 5, version 44, subversion 0 (v5.44.0) built for darwin-2level
necromant ★★★
()
Ответ на: комментарий от zabbal

Лет 19 точно. Я в последний раз писал на Perl новый проект за деньги в 2007 году. И то, мне уже тогда казалось удивительным, что кто-то в 2007 году ещё готов платить деньги за Perl.

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

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

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

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

Кстати да, обидно, что начиная с 2005 года культура у перловиков сильно выросла, появились линтеры и идея самоограничений ради читателя, modern perl, вот это всё. А реальный код почти всегда это ужос чуть не из 90-х.

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

Тоже не слышал. Но в обновлениях ОС периодически проскакивают какие-то перловские пакеты, так что легаси, видимо, ещё живет.

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

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

MusicBrainz все еще на Perl (а вот новые проекты MetaBrainz уже на Python)

А из компаний раньше был Booking, который как пылесос забрал к себе всех с рынка (не знаю, продолжают они его использовать или нет)

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

чаму не на самом перле?

perl -V|perl -wnl -e ‘/config_args=/ and print;’

mumpster ★★★★★
()

Ура, товарищи! Славный язык.

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

Что вам приходится пересобирать-то? Только если XSки. На мой взгляд самый стабильный язык на данным момент. Код который был написан в 2005м году (не 5 строчек) работает до сих пор, в отличии от так популярного нынче питона или пхп.

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

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

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

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

Без понятия. Могу только сказать, что года после 2009 я вообще не видел предложений работы на Perl. Ни на сайтах вакансий, ни в предложениях для фрилансеров. М.б. бывали 1-2 вакансии в год. Последние лет 9 даже этого нет.

Допускаю, что все истинные перловики друг-друга знают, и все находят работу благодаря сарафанному радио.

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

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

Без понятия. Могу только сказать, что года после 2009 я вообще не видел предложений работы на Perl. Ни на сайтах вакансий, ни в предложениях для фрилансеров. М.б. бывали 1-2 вакансии в год. Последние лет 9 даже этого нет.

я в 2009 начал стартап на Perl и до 2018 года мы нанимали перловиков. Потом нас купил Яндекс и внутри него уже был стандартом Python.

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

Без понятия. Могу только сказать, что года после 2009 я вообще не видел предложений работы на Perl. Ни на сайтах вакансий, ни в предложениях для фрилансеров. М.б. бывали 1-2 вакансии в год. Последние лет 9 даже этого нет. Их, конечно сильно меньше, чем на остальных языках, но они периодически попадаются.

Допускаю, что все истинные перловики друг-друга знают, и все находят работу благодаря сарафанному радио. Нет :)

У перла есть серьезное преимущество перед тем же питоном. Как я уже писал, то, что написано в 2005м году до сих пор работает на свежих версиях перла без каких-либо изменений. А с питоном я не сильно сложные скрипты правлю достаточно регулярно, а про пхп с их 7й и 8й версией я вообще молчу.

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

Perl собирается минут 5-10 на моём железе. XS-модули надо смотреть, они разные есть и зависит от количества. У меня лично на десктопе их полторы штуки. Остальное собирать не надо, оно же интерпретируемое. И в отличие от питона их не надо переписывать при каждом минорном релизе.

shell-script ★★★★★
()

Такое ненужно, что может даже и нужно..

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

даже не emerge, если python-updater ушел как ненужная сущность, то обновление Perl
без perl-cleaner --all (-v — -ab) не обходится никак, и там не только «xs-ки», там еще и то что слинковано с libperl (вон выше llvm упомянули), так что хорошо, если это будет мелочь типа git


Так что, весьма и весьма неудобный для обновления пакет.

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

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

Правда, того же llvm у меня нет. Вот с ним вечно проблемы. Одна из причин, по которой я ставлю rust-bin, а не компиляю его, например.

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

Хотя, может быть, у меня проблем нет, потому что я не на тильде(размаскировано всего несколько десятков пакетов) и ко мне свежая версия прилетает попозже, когда уже всё оттестируют.

shell-script ★★★★★
()

Отличная новость. В perlbrew уже прилетел. Для части своего софта обновил, буду пробовать.

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

perl-cleaner -all -v — -ab

Я дженту обновляю реже, чем раз в год, поэтому с танцами, но до «additional command line options for the package manager» ещё ни разу не добрался.

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

У перла есть серьезное преимущество перед тем же питоном. Как я уже писал, то, что написано в 2005м году до сих пор работает на свежих версиях перла без каких-либо изменений.

Ну, допустим. Только это единственное преимущество, пожалуй. )

Так-то я хотя и писал несколько раз на Perl, и первое время по любви, и даже за деньги, но всё-таки моё мнение однозначное: это write-only язык.

Можно спорить до морковкиного заговения о языках. Что лучше, функциональные или процедурные, допустимо ли ООП, каким должно быть ООП, интерпретируемые или компилируемые, треды или процессы или корутины, и т.д. и т.п. Но практически любой используемый сейчас язык будет гораздо читаемее и понятнее Perl’а. И это, подозреваю, одна из основных причин, почему Perl умер.

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

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

На мой взгляд самый стабильный язык на данным момент. Код который был написан в 2005м году (не 5 строчек) работает до сих пор

Это ничего не говорит о собственно языке - только о программисте, писавшем этот код, да ещё, пожалуй, об его удачливости... ;))

в отличии от так популярного нынче питона или пхп.

Ой, ой!... :))

PHP. Код, написанный до 2005 года, таки тоже «работает до сих пор». ;))

Но мне не приходит в голову считать это оценкой «стабильности языка» (кстати, а что это такое, вообще?? Ж8-О ;P ;)) ). Для меня это просто показатель качества конкретного программного решения конкретной прикладной задачки.

Ах, да! Тоже «не 5 строчек»!.. ;P ;)) И даже не 6... :))

Так что вспомним, «из классиков»: «Программы пишут не компиляторы, а программисты». :)

Ровно то же самое можно сказать и об интерпретаторах... ;))

Не язык определяет условное «качество программного продукта», а «погромист(ы)» - самый «нестабильный элемент» всей этой «системы». :)

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

PHP. Код, написанный до 2005 года, таки тоже «работает до сих пор». ;))

Вот это ложь. Если учесть, что php - это язык, ориентированный на создание сайтиков, т.е. вывод текста и то, что в те времена он не умел в многобайтовые кодировки и любые функции для работы со строками работали не с «символами», а с байтами, после массового внедрения UTF-8 разрабы языка ввели целый ворох костылей типа «substr -> mb_substr» и, соотвенственно, весь код нужно было переписать с использованием этих mb_*, ничего там до сих работать не может по определению. И тупой автозаменой по всему коду регекспом этого сделать нелья, так как в php нет стандарта по именованию функций и название одной функции может быть в середине названия другой.

Это первое, что приходит на ум.

Второе - это изменение определения самих функций.

Третье, выкидывание кучи модулей в минорных релизах.

И так далее. Мне лень вспоминать уже. Я стараюсь забыть это как страшный сон.

У питона с этим чуть получше, но у них другая проблема. Они любят менять синтаксис на ровном месте без сохранения обратной совместимости. Причём я не про python2/python3 говорю. Я про минорные релизы. Только недавно у себя в gentoo обновлял python3.13 на python3.14. И это опять была боль. И у меня ещё легко прошло. Всего лишь несколько пакетов конфликтовали и пришлось немного потанцевать. А не уютном гентушном канале люди, у которых больше софта на python завязано, чем у меня, народ матерился по-страшному.

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

И вот как в случае с perl, если ты нормальный(не гениальный) программист, который хоть немного придерживается рекомендаций и общепринятых правил по кодстилю, это очень читабельный язык, где с первого взгляда понятно, что там происходит, и куда надо копать. Да, можно писать write-only с выпендрёжем и хитровымученными конструкциями. Но зачем?! Хотя даже такой код, написанный под какой-нибудь 5.10 будет работать в 5.44. В крайнем случае, нужно будет добавить директиву use «вставить нужную версию», если за двадцать лет какую-то функцию депрекейтнули, а программисты все эти двадцать лет игнорировали warning о том, что эта функция скоро депрекейтнут.

И точно так же я могу и python назвать write-only, когда какой-нить программист, например, пишет метод на 100500 строк с несколькими десятками вложенных циклов, условий и прочего, так что если ты находишься где-нить в середине этого метода, из-за отступов вместо скобочек просто невозможно понять, на каком уровне этот код выполняется. И проще всё выкинуть и сделать заново. Но тут у меня тот же вопрос. Зачем так писать?

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

Только недавно у себя в gentoo обновлял python3.13 на python3.14. И это опять была боль. И у меня ещё легко прошло. Всего лишь несколько пакетов конфликтовали и пришлось немного потанцевать.

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

Из любопытства, пример можно? А то я не сталкивался.ъ

bbc69
()
Ответ на: комментарий от shell-script

Вот это ложь.

Обоснуй. А пока что это ты лжец и клеветник.

Если учесть, что php - это язык, ориентированный на создание сайтиков, т.е. вывод текста и то, что в те времена он не умел в многобайтовые кодировки и любые функции для работы со строками работали не с «символами», а с байтами, после массового внедрения UTF-8 разрабы языка ввели целый ворох костылей типа «substr -> mb_substr» и, соотвенственно, весь код нужно было переписать с использованием этих mb_*, ничего там до сих работать не может по определению.

А вот эти твои фантазии-то тут при чём??.. Но таки да, соглашусь, что «ничего там до сих работать не может по определению» - для невежд, не умевших применить PHP ни для чего, кроме «создания сайтиков» и «вывода текста».

А текст, к слову, не всегда и не всякий требовал и требует «многобайтовых кодировок», junior... ;)))

И тупой автозаменой по всему коду регекспом этого сделать нелья, так как в php нет стандарта по именованию функций и название одной функции может быть в середине названия другой.

А ты попробуй не «тупой»... ;))

Это первое, что приходит на ум.

Это если он есть... ;))

Но тут у меня тот же вопрос. Зачем так писать?

А у меня к тебе другой вопрос: зачем так фантазировать??.. ;))

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

По секрету, только тебе: попытайся, хотя бы, представить себе, что даже на «языке, ориентированном на создание сайтиков», можно писать нечто, что не требует ни «работы со строками», ни чего-то подобного - ничего из того, что тебе прибредилось... :)

В общем, либо извиняйся за «ложь», (хотя... я не думаю, что ты на это способен) либо поднатужься и придумай что-нибудь более правдоподобное... И не связанное с тем, что ты уже навыдумывал. :

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

А вот эти твои фантазии-то тут при чём?

Ну рассскажи аргументированно, в чём я не прав? Не голословными заявляниями про фантазии, а конкретно по пунтам.

А текст, к слову, не всегда и не всякий требовал и требует «многобайтовых кодировок», junior..

Я вообще не программист. Но пишу много и часто. И ревью программистам провожу, и патчи засылаю. Но это к делу не относится. Ты там выше писал, что perl используются в девяти конторах. Вот так же и однобайтовые кодировки в 21-ом веке применяют три с половиной аннонимуса. Senior'чик ты наш. Даже, когда я занимался переносом кода с очень древнего solaris'а на redhat'ы в одном международном банке, мы уже включали UTF по требованию заказчика. А код там был начиная с 70-ых и заканчивания 90-ыми. Потому что им в начале 2000-ых уже нужен был UTF для работы.

А ты попробуй не «тупой»...

А не тупой тоже не получится. Почему, я написал.

Это если он есть...

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

По секрету, только тебе ... можно писать нечто, что не требует ни «работы со строками»

По секрету только тебе: некоторые и на баше пишут всё, что угодно. Но зачем? Я прекрасно знаю, что и как пишут на php. Всякое повидал. Но в мейнстриме это на уровне погрешности.

Итого: от тебя я пока не услышал ни одного аргумента, только оскорбления и какие-то усмешки.

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

shell-script ★★★★★
()
Ответ на: комментарий от Chiffchaff

практически любой используемый сейчас язык будет гораздо читаемее и понятнее Perl’а

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

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

Из любопытства, пример можно?

Был такой пакет - app-arch/p7zip. У него в зависимостях был x11-misc/shared-mime-info. А у последнего, в свою очередь, как сам python, так и пачка других пакетов, которые тянули разнообразные питоновские либы. app-arch/p7zip судя по всему разрабы забросили. А в x11-misc/shared-mime-info после перехода на 3.14, поменялось поведение, так как какие-то вызовы выплёвываются напрямую из питоновских скриптов. И мантейнеры gentoo жёстко замаскировали на уровне профиля app-arch/p7zip. Пришлось быстренько подискать замену(благо сами мантейнеры в причинах маскировки дали несколькоо рекомендаций) и это подставить. Т.е. получается что из-за 3.13 -> 3.14 добавилось работы всем, кто от питона зависит даже косвенно. Тут можно, конечно, попинать и разработчиков x11-misc/shared-mime-info, что не стали тратить время на написание обёрток над свзанными с питоном функциями и не сохранили обратную совместимость. Но тут есть нюанс: сам x11-misc/shared-mime-info не менял версию. Повторюсь, он просто вызывает в каких-то случаях питоновские скрипты, а вот эти скрипты из-за обновления минорной версии стали вести себя иначе. Это самое запоминающееся.

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

Если тебя интересуют именно куски кода, то я так глубоко не влезал, я в таких ситуациях доверяю мантейнерам.

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

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

То, что PHP ломает обратную совместимость, показать довольно просто: попробуйте на https://onlinephp.io/ выбрать 8.x и 5.x и ввести

<?php
print_r(implode(["1","2"], "|"));
Будет
Result for 8.0.30:
Fatal error: Uncaught TypeError: implode(): Argument #2 ($array) must be of type ?array, string given in /home/user/scripts/code.php:2
Stack trace:
#0 /home/user/scripts/code.php(2): implode(Array, '|')
#1 {main}
  thrown in /home/user/scripts/code.php on line 2

Result for 5.4.45:
1|2

Но товарищ, с которым вы разговариваете, неадекватен, поэтому смысла в такой демонстрации не будет.

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