Python 3.14

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

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

Неужели даже это требуется объяснять??.. ;) :))

И да, «исчезнувшие» таким образом отступы труднее восстановить, чем «исчезнувшие» же скобки. Почему, надеюсь, понятно без объяснений...

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

А каким образом «отступы» заменились вдруг на «переводы строки»?? ;))

На это я отвечу только, что я лет 30 разрабатываю для себя и профессионально, и ни разу с такой проблемой не сталкивался. Я не знаю, что такое надо запустить, какой редактор, чтобы это произошло.

Открыть исходник в MS Word?

Ожидаемо... нечего сказать... :)

На каждый абсурдный воображаемый недостаток возражений не напасёшься.

возражений не напасёшься

Но «ярлычки расклеить» силёнки таки нашлись... :D

Я про «абсурдный» и «воображаемый».

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

Я попросил привести прмер, где и когда удаляются, ну пускай, пробельные символы

Неправда. Изначально речь шла про «отступы», а не про «пробельные символы».

И я ответил. И да, именно, «отступы» разными редакторами интерпретируются по-разному. Даже один и тот же редактор, в зависимости от настроек, может менять фактическую ширину «отступа» на экране. Пример: настройка «шага» табуляции...

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

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

Да даже если изменить физически, если изменение происходит согласовано (8 пробелов в таб, таб в 8 пробелов), то поведение тоже не изменится.

Не говоря уж о том, что уже лет 15-20 в Python стандарт де-факто, навязываемый всеми инструментами: 4 пробела и никаких табов, и я уже даже в самом лютом говнокоде не видел отступлений от этого правила.

Ну там не в каждом, через релиз получается, 3.12 сделали быстрым, 3.13 чёт подзамедлился, 3.14 снова быстрый. Но проблема не в этом, а в том что 3.9 уже почти еол, а значит придётся всё эти питорчи и тензорфловы обновлять, и опять куча всего сломается.

Во-первых, можно не обновляться. Во-вторых, как человек, который перетаскивал огромные сервисы с 3.6 на 3.7 на 3.8 на 3.9 и далее, вплоть до 3.13 - обычно смена версии происходит легко. Не ломается почти ничего.

Кроме сломанных зависимостей, когда автор какой-то зависимости описал транзитивные зависимости от балды. Но тут разные стратегии есть: немного подождать, пока автор исправит. Завендорить проект в своё дерево.

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

Например, на .NET их не шибко то много, даже родной VB.NET и тот лишь в режиме поддержки совместимости.

Хотелось бы узнать, есть ли в JRuby какие-нибудь серъёзные недостатки для написания CLI утилит кроме того, что нужен JVM?

В Alpine контейнере вероятно можно упаковать и JRuby и JVM по объёму около 100 Mb, - по нынешним временам это ведь совсем немного.

Какой самый лучший обфускатор для .class выхлопа JRuby?

Подойдёт ли Skidfuscator?

Кстати, для CPython я так и не нашёл нормального обфускатора, PyArmor мне не понравился своей лицензионной политикой. Nuitka - это уже не то.

А если сравнивать именно с JRuby, то и Jython и IronPython находятся в каком-то сильно отсталом состоянии по сравнению с оригинальным CPython, что вероятно намекает на сложность подобного портирования именно пятона. Хотя JRuby вроде сильно не отстаёт от своего оригинала?

Интересно почитать исторические комментарии про первые удачные релизы JRuby и даже то, что происходило до них:

Разработчики JRuby переходят на работу в Sun

Чего только ему не пророчили около 20-и лет назад, в т.ч. и в плохом смысле, а ведь теперь JRuby один из лучших foreign ЯП для JVM?

Ещё бы прикрутили опции как в VB:

Option Strict
Option Explicit

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