Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск языка программирования Python 3.15"	+/–
Сообщение от opennews (??), 10-Окт-26, 13:23
После года разработки опубликован значительный выпуск языка программирования Python 3.15. Среди изменений: включение по умолчанию UTF-8, отложенная загрузка модулей, оптимизация экспериментального JIT-компилятора, типы  frozendict и sentinel, файлы конфигурации для инициализации при запуске, расширение возможностей для профилирования, сборка в режиме "-fno-omit-frame-pointer" и встроенная текстовая игра "whatsnewt". Новая ветка будет поддерживаться в течение полутора лет, после чего ещё три с половиной года для неё будут формироваться исправления с устранением уязвимостей... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66438
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

3. "Выпуск языка программирования Python 3.15"	–2 +/–
Сообщение от Аноним (3), 10-Окт-26, 13:42
> В качестве кодировки по умолчанию задействована UTF-8 А что до этого было в третьебидоне?
Ответить | Правка | Наверх | Cообщить модератору

	6. "Выпуск языка программирования Python 3.15"	–21 +/–
	Сообщение от сиська (?), 10-Окт-26, 14:19
	как обычно - мусорный, однобайтный ansi, скорей всего
	Ответить | Правка | Наверх | Cообщить модератору

	7. "-"	+10 +/–
	Сообщение от Аноним (7), 10-Окт-26, 14:19
	Кодировка бралась из системной локали
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	54. "-"	+2 +/–
	Сообщение от Ананимер (?), 10-Окт-26, 19:31
	Программисты так и не переключились с парадигмы «кодировка - атрибут архитектуры» на «кодировка - атрибут строки». Ведь это целая лишняя проверка при сравнении строк.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "-"	+/–
	Сообщение от Аноним (-), 11-Окт-26, 16:13
	Так со строками все было нормально с появления трешки, там юникод. Речь про ввод-вывод.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "-"	+/–
	Сообщение от Аноним (3), 12-Окт-26, 11:41
	Т.е. впринципе актуально в основном только для форток и некоторых ретроградов. Но всё равно пахнет как достаточно мажорный breaking change с которым мажорную версию стоило бы бампнуть
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	8. "Выпуск языка программирования Python 3.15"	+9 +/–
	Сообщение от User (??), 10-Окт-26, 14:32
	"Ничего". Удивительно, да? Создатели языка считали, что если программист явным образом не изъявил желание написав encoding="utf-8", то параметр определяется платформой\пользователем. Хочет человек работать с koi8r - пусть работает, да. Но так как племя молодое, незнакомое о существовании чего-либо отличного от - не в курсе, пришлось вот приколачивать руками.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	24. "Выпуск языка программирования Python 3.15"	–3 +/–
	Сообщение от Аноним (24), 10-Окт-26, 15:38
	> Но так как племя молодое, незнакомое о существовании чего-либо отличного от - не в курсе, пришлось вот приколачивать руками. Это были тёмные времена, хорошо что они позади. Вот ещё потихоньку отмирают сишные динозавры с мантрой "строка - это массив байт", забирая с собой целую эпоху уязвимостей. В ходе эволюции программирования всякие странные "плавники" и "ложноподии" отращивались, пришло время подчистить тупиковые ветки.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "-"	+10 +/–
	Сообщение от Аноним (26), 10-Окт-26, 15:49
	А что такое строка, если не массив байт?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "-"	+4 +/–
	Сообщение от xPhoenix (ok), 10-Окт-26, 18:07
	На размышление даётся строка Unicode, где каждый символ закодирован либо одним либо двумя байтами.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "-"	–6 +/–
	Сообщение от Тот_Самый_Анонимус_ (?), 10-Окт-26, 18:39
	Что есть вселенское зло. Нигде не нужен одновременно весь массив символов юникода.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "-"	+/–
	Сообщение от Аноним (45), 10-Окт-26, 18:49
	> Что есть вселенское зло. Нигде не нужен одновременно весь массив символов юникода. Зло-то оно конечно зло. Но бнопня как-то тоже ничем не лучше была.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "-"	–1 +/–
	Сообщение от Тот_Самый_Анонимус_ (?), 10-Окт-26, 19:16
	> Зло-то оно конечно зло. Но бнопня как-то тоже ничем не лучше была. Кодировка с равной длиной символа — вот выход.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "-"	–1 +/–
	Сообщение от Аноним (66), 10-Окт-26, 20:09
	Разумеется, у людей лишняя память проставивает, давайте раздуем потребление раза в два-три.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "-"	+/–
	Сообщение от Тот_Самый_Анонимус_ (?), 12-Окт-26, 06:53
	Так может быть кодовые страницы не так уж и плохи? А то нелатиница так же страдает от потерь памяти, но всем всё равно.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "-"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 16:53
	А вы считали? Возьмём однобайтную кодировку: поверх ascii остаётся всего 128 символов. Это мало, одна только кириллица из русского языка без буквы ё в разном регистре уже займёт 50% адресного пространства. Если брать двухбайтные кодировки, то это уже гарантированное увеличение размера памяти. Адресного пространства двух байт хватит на 65536 символа, но существует китайский, корейский, японский. Для них нужно либо разбивать один символ на несколько частей, что уже снижает потребление памяти, но делает длину символа снова переменной(либо два байта, либо четыре), либо выкидывать часть символов, делая их набор невозможным, либо всё-таки растянуть размер более чем на два байта. И это всё без учёта эмодзи.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "-"	+/–
	Сообщение от Аноним (95), 11-Окт-26, 04:58
	>Кодировка с равной длиной символа — вот выход. UTF-32 - Юникод в своей природной форме, без всяких фокусов.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	58. "-"	+/–
	Сообщение от Аноним (66), 10-Окт-26, 19:52
	Что вы предлагаете в качестве замены? По кодировке на каждую программу? Постоянные потери символов? Невозможность использование программы за пределами страны автора?
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	161. "-"	+1 +/–
	Сообщение от Тот_Самый_Анонимус_ (?), 12-Окт-26, 07:34
	> Что вы предлагаете в качестве замены? По кодировке на каждую программу? Постоянные потери символов? Невозможность использование программы за пределами страны автора? 1. Минимум две кодировки: клоунская и рабочая. Клоунская — для чатов, форумов. Рабочая — для работы (нет никакой надобности называть файлы клинописью и смайликами). 2. Избавление юникода от расизма, сексизма и навязывния извращений: например зачем рукопожатия с разными оттенками кожи(🤝🏻, 🤝🏽, 🤝🏿); смайлики, разделённые на мужские и женские, или выделение гомопар среди пар, или бородатые женщины? Я вижу в этом протаскивание политической повесточки, а не техническую необходимость. Вот всю эту гадость надо в клоунскую кодировку (см. выше). 3. Чистка от неиспользумых символов: клинопись и египетские иероглифы могут быть вынесены в отдельную кодировку, или вообще в отдельный шрифт, использующий текущую. Римские цифры в большинсве есть латинские буквы, отдельных символов они не требуют. Итого: двух байт на кодировку с постоянной шириной символа хватило бы.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "-"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 17:04
	>1. Минимум две кодировки: клоунская и рабочая. Вы выбрали >По кодировке на каждую программу? Постоянные потери символов? Только почему-то этого не описали >нет никакой надобности называть файлы клинописью и смайликами А при чём тут файлы? Кроме файлов кодировка много где нужна, например, в элементах интерфейса. >2. Избавление юникода от расизма, сексизма и навязывния извращений Это касается только эмодзи. >Чистка от неиспользумых символов: клинопись и египетские иероглифы могут быть вынесены в отдельную кодировку Что насчёт китайских иероглифов? >или вообще в отдельный шрифт, использующий текущую Это - плохой вариант. Достаточно просто скопировать текст в буфер обмена, чтобы потерять информацию о правильном отображении символов.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "-"	+/–
	Сообщение от Тот_Самый_Анонимус_ (?), 13-Окт-26, 14:47
	> Вы выбрали Предложил. Или нафантазировал. Всё равно решения принимают люди, преследующие свои интересы, а не думающие об эффективности. > Только почему-то этого не описали Есть разница между «По кодировке на каждую программу» и «несколько общих упорядоченных кодировок». > А при чём тут файлы? Это один из примеров рабочих задач. > Кроме файлов кодировка много где нужна, например, в элементах интерфейса. Ну я привёл ненужные примеры клинописи и египетских иероглифов. В более  изощрённых случаях можно использовать отдельный шрифт дл я интерфейса. > Это касается только эмодзи. Да. Юникод в основном в эту сторону и расширяется. Так сказать «горшочек не вари». > Что насчёт китайских иероглифов? Кто-то насчитал их около 40 тысяч. Со всеми другими символами можно уложиться в два байта. Равная длина всех символов. > Это - плохой вариант. Достаточно просто скопировать текст в буфер обмена, чтобы  потерять информацию о правильном отображении символов. Это отличный вариант. Он позволяет выдумывать свои алфавиты, не захламляя таблицу кода. Например есть эльфийские алфавиты, выдуманные Толкиеном. Возможно юникод, вслед за бородатой женщиной, добавит и эти символы. Только вот зачем? И вы не потеряете текст, скопировав его в буфер, он будет отображать те символы, которыми закодирован. Останется выбрать нужный шрифт.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "-"	+/–
	Сообщение от Аноним (66), 13-Окт-26, 15:06
	>Есть разница между «По кодировке на каждую программу» и «несколько общих упорядоченных кодировок». Если я активно использую две/три программы, то это и будет по кодировке на программу. Когда условный терминал кодировку не поддерживает, а текстовой редактор - поддерживает. >Это один из примеров рабочих задач. Только проблема в том, что нужно гарантировать, что данной необходимости нет, и она не возникнет. Вот терминал - должен уметь отображать эмодзи или нет? >Кто-то насчитал их около 40 тысяч. Распространённых. Проблема в том, что редкие такими темпами отображать не получится. >И вы не потеряете текст, скопировав его в буфер, он будет отображать те символы, которыми закодирован. Останется выбрать нужный шрифт. Для этого, нужно знать, какой фрагмент чем закодирован. Если копировать большой текст, где в перемешку будет идти как новый алфавит, так и старый, потеря данных при конвертации будет либо необратимой, либо долго исправимой. Например, нельзя будет скопировать сразу сотню страниц, так как всё сольётся воедино. Удобство работы с таким текстом сильно упадёт, например, его не получится скопировать в vim.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "-"	+/–
	Сообщение от Тот_Самый_Анонимус_ (?), 13-Окт-26, 17:56
	>Если я активно использую две/три программы, то это и будет по кодировке на программу. Когда условный терминал кодировку не поддерживает, а текстовой редактор - поддерживает. >Вот терминал - должен уметь отображать эмодзи или нет? Не должен. Пример с составными символами (те самые рукопожатия) тут важен. >Распространённых. Распространённых — не более десятка тысяч. Вы слишком хорошего мнения о китайцах, если считаете, что среднестатистический образованный китаец знает и помнит 40 тысяч знаков. >Для этого, нужно знать, какой фрагмент чем закодирован. Если копировать большой текст, где в перемешку будет идти как новый алфавит, так и старый, потеря данных при конвертации будет либо необратимой, либо долго исправимой. Например, нельзя будет скопировать сразу сотню страниц, так как всё сольётся воедино. Удобство работы с таким текстом сильно упадёт, например, его не получится скопировать в vim. Это надуманная проблема и решается она отдельной кодировкой под, допустим, научные задачи, где могут встречаться символы как клинописи, так и китайского письма, египетских иероглифов, математических формул, и смайликов, изображающих извращенцев. Такая кодировка не считается с потерей памяти и нужна менее чем одному проценту пользователей и тянуть её везде — пустая трата ресурсов.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "-"	+/–
	Сообщение от Аноним (66), 14-Окт-26, 11:33
	>Не должен. Пример с составными символами (те самые рукопожатия) тут важен. Сами по себе рукопожатия несут отрицательную ценность для меня, а вот невозможность скопировать произвольный текст в условный терминальным vim - неприятна. >Распространённых — не более десятка тысяч. Вы слишком хорошего мнения о китайцах, если считаете, что среднестатистический образованный китаец знает и помнит 40 тысяч знаков. Какое мне дело до китайцев? Важно то, какой потенциальный вред отсутствие иероглифа нанесёт мне. А вред прямой: в случае необходимости, не получится просто так скопировать текст из условного блокнота в браузер. Фактически, как только я начну взаимодействовать с китайским, мне нужно будет как минимум отдельный блокнот и отдельный браузер ставить. >китайского письма, египетских иероглифов, математических формул, и смайликов, изображающих извращенцев Математические формулы записываются с помощью разметки, а не кодировки >Такая кодировка не считается с потерей памяти Предложенный вами вариант увеличит потребление памяти для ascii текстов гарантированно, и только потенциально может уменьшить, для всяких cjk. >нужна менее чем одному проценту пользователей Про универсальность вы даже не думаете
	Ответить | Правка | Наверх | Cообщить модератору

	241. "-"	+/–
	Сообщение от Тот_Самый_Анонимус_ (?), 14-Окт-26, 12:32
	>Сами по себе рукопожатия несут отрицательную ценность для меня, а вот невозможность скопировать произвольный текст в условный терминальным vim - неприятна. Проблема решаема. Буфер обмена для приложений, а не для способа их запуска. >Какое мне дело до китайцев? Важно то, какой потенциальный вред отсутствие иероглифа нанесёт мне. А вред прямой: в случае необходимости, не получится просто так скопировать текст из условного блокнота в браузер. Несколько стандартизированных кодировок и знание программ о их существовании всполне решают проблему. >Математические формулы записываются с помощью разметки, а не кодировки Умничать не надо. Уйма формул записываются без всяких редакторов. Я имел в виду специфичные для математики скобки и прочее. >Предложенный вами вариант увеличит потребление памяти для ascii текстов гарантированно И что? Разработчиков стандарта не волнуют проблемы кириллистических текстов, которые от юникода пухнут. Почему латиница должна иметь привелегии? >Про универсальность вы даже не думаете Юникод давно уже не про универсальность, а про потребность корпораций в сомнительных значках и о политической повесточке (ведь это было архиважно добавлять в кодовую таблицу смайлик с бородатой женщиной!). Причём разница в размерах символов не позволяет читать текст с произвольного места.
	Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

	87. "-"	–2 +/–
	Сообщение от Аноним (26), 10-Окт-26, 23:28
	А символы это не байты? Т.е получается строка это массив байт, которые инетрпретируются через опред.кодировку
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	89. "-"	+1 +/–
	Сообщение от минона (?), 11-Окт-26, 00:49
	> На размышление даётся строка Unicode, где каждый символ закодирован либо одним либо двумя байтами. А где это так происходит? Хинт: точно не в UTF-8. ЕМНИП, в UTF-8 символ до 6 байтов.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	96. "-"	+1 +/–
	Сообщение от Аноним (95), 11-Окт-26, 04:59
	От 1-го и до 6 байтов. Это резиновая кодировка.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "-"	+/–
	Сообщение от _ (??), 11-Окт-26, 05:05
	И что это изменяет в утверждении выше? Пистонщики конечно эпические... мннэээ... программеры :) Оооо! Байт или два говоришь? Народ у пистонциков то юникод - кривой!, стандарт прочитать и понять оне не в силях! :) :-Р
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	41. "-"	+2 +/–
	Сообщение от Агл (ok), 10-Окт-26, 18:38
	это магия
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	44. "-"	–1 +/–
	Сообщение от Я (??), 10-Окт-26, 18:47
	Волшебство!) Как же раньше, примерно, 30 лет назад все было просто (
	Ответить | Правка | Наверх | Cообщить модератору

	63. "-"	+3 +/–
	Сообщение от xPhoenix (ok), 10-Окт-26, 19:58
	> Волшебство!) Как же раньше, примерно, 30 лет назад все было просто ( "Просто" было ещё в 2006 году. Matlab в Windows не сохранял проект, если логин пользователя содержал символы за пределами ASCII.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "-"	+/–
	Сообщение от Аноним (127), 11-Окт-26, 16:12
	Зачем в логине пользователя иметь символы за пределами ASCII?
	Ответить | Правка | Наверх | Cообщить модератору

	135. "-"	+/–
	Сообщение от Аноним (66), 11-Окт-26, 18:17
	С чего вы взяли, что проблема была только в логине пользователя, а не полном пути к файлу?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "-"	+/–
	Сообщение от _ (??), 11-Окт-26, 23:50
	А почему "эти двое - оба ко мне" - должны вообще быть проблемой? И в логине и в путях естественно ожидать символы того что юзается юзером. Уж в 2к26 - то, софт который так не умеет - бракованный!, его надо просто выкинуть. Как бе - компьютер - для людей, а не наеборот! :)
	Ответить | Правка | Наверх | Cообщить модератору

	43. "-"	+2 +/–
	Сообщение от Аноним (45), 10-Окт-26, 18:46
	> А что такое строка, если не массив байт? Строка - это массив символов. И если пытаться работать с ним как с массивом байт, то будет как у классика: "о сколько нам открытий чудных ...". Не, можно попробовать спереть машину времени и вернуться в древние времена однобайтных кодировок, но там тоже будут Чудеса (просто другого вида).
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	113. "-"	+/–
	Сообщение от ptr (ok), 11-Окт-26, 10:16
	> Строка - это массив символов. А символ - это массив байтов. Из чего получаем, что строка - это тоже массив байтов. > если пытаться работать с ним как с массивом байт Назовите мне хотя бы одну машинную команду любой архитектуры, умеющую работать с символами UTF-8, а не байтами. Другой вопрос, что у программиста всегда есть возможность воспользоваться готовым кодом, работающим с массивом байтов, но предоставляющим в интерфейсе абстракции для массивов символов.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "-"	+/–
	Сообщение от User (??), 11-Окт-26, 12:02
	Ну как будто бы - осталось очень и очень немного причин работать с "массивами символов" на уровне машинных команд, нет?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "-"	+/–
	Сообщение от ptr (??), 11-Окт-26, 17:22
	> Ну как будто бы - осталось очень и очень немного причин работать > с "массивами символов" на уровне машинных команд, нет? Но отсутствие у программиста понимания того, в какие машинные команды на целевой архитектуре преобразуются вызовы тех функций или методов, которыми он пользуется, явно снижает его ценность, как специалиста. Особенно, если речь идет о встраиваемых системах и протоколах коммуникации. Не говоря даже об SPI, I2C и т.п., а ограничившись отладкой при парсинге UDP пакета, которые представляет собой в чистом виде массив байтов, разбираться с "массивами символов" в этом массиве байтов всё равно потребуется.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "-"	–1 +/–
	Сообщение от User (??), 11-Окт-26, 18:53
	>> Ну как будто бы - осталось очень и очень немного причин работать >> с "массивами символов" на уровне машинных команд, нет? > Но отсутствие у программиста понимания того, в какие машинные команды на целевой > архитектуре преобразуются вызовы тех функций или методов, которыми он пользуется, явно > снижает его ценность, как специалиста. В контексте вот python'а то? Смеётесь, да? И java'ы - нет. И c#. И даже с go вот примерно пофиг. > Особенно, если речь идет о встраиваемых  системах и протоколах коммуникации. Не говоря даже > об SPI, I2C и т.п., а ограничившись отладкой при парсинге UDP пакета, которые представляет > > собой в чистом виде массив байтов, разбираться с "массивами символов" в этом > массиве байтов всё равно потребуется. Ну, тут вот спорить не буду - далековато оно от меня. Но глядя на какой-нибудь micropython ка-жет-ся мне что и во встраиваемых системах эта самая граница за последние 30 лет си-и-ии-и-ильно так "вверх" уехала.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "-"	+/–
	Сообщение от ptr (??), 11-Окт-26, 19:26
	> В контексте вот python'а то? Смеётесь, да? https://wiki.python.org/python/EmbeddedPython.html
	Ответить | Правка | Наверх | Cообщить модератору

	143. "-"	+/–
	Сообщение от User (??), 11-Окт-26, 19:44
	>> В контексте вот python'а то? Смеётесь, да? > https://wiki.python.org/python/EmbeddedPython.html Ну и как, часто от python-программистов на собеседовании этого вот просят, если в вакансии явным образом про EMBEDDED\MICRO не написано? И сколько этих - где написано - относительно общего количества?
	Ответить | Правка | Наверх | Cообщить модератору

	152. "-"	+/–
	Сообщение от ptr (??), 11-Окт-26, 21:46
	> Ну и как, часто от python-программистов на собеседовании этого вот просят Ну если программист до пенсии собирается оставаться джуном, то для него подобные знания точно излишни ))) А если серьёзно, то ориентироваться на нижнюю планку знаний - плохая идея в любой области.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "-"	+/–
	Сообщение от User (??), 12-Окт-26, 08:23
	>> Ну и как, часто от python-программистов на собеседовании этого вот просят > Ну если программист до пенсии собирается оставаться джуном, то для него подобные > знания точно излишни ))) > А если серьёзно, то ориентироваться на нижнюю планку знаний - плохая идея > в любой области. Ненене. Если программист не работает в очень-очень узкой специальности байтодро4ером - то примерно в 100% случаев время лучше потратить на знакомство с предметной областью и\или набором инструментов, упрощающих ту работу. Ну согласитесь, претензии к сишникам по поводу неумения работать с осцилографом, или незнания того, сколько транзисторов нужно для формирования логических элементов по типу сейчас немножечко так смешны? От того, что я это после института умел\знал - моя ценность как специалиста зависит ээээ... "никак".
	Ответить | Правка | Наверх | Cообщить модератору

	170. "-"	+/–
	Сообщение от ptr (??), 12-Окт-26, 10:08
	> Ненене. Если программист не работает в очень-очень узкой специальности байтодро4ером Вот именно потому и писал выше о джунах, которые в принципе не способны диагностировать ошибку в собственном коде, анализируя сетевые пакеты. Даже если эти сетевые пакеты между их же сервисами внутри k8s )))
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	184. "-"	+/–
	Сообщение от User (??), 12-Окт-26, 12:36
	>> Ненене. Если программист не работает в очень-очень узкой специальности байтодро4ером > Вот именно потому и писал выше о джунах, которые в принципе не > способны диагностировать ошибку в собственном коде, анализируя сетевые пакеты. Даже если > эти сетевые пакеты между их же сервисами внутри k8s ))) Оу. Ну, если у вас программисты "между нод" с tcpdump'ом ползают по тому, что без этого никак-никак не разобраться что там и как - то в этой консерватории очень-и-очень не так примерно ВСЁ.
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	187. "-"	+/–
	Сообщение от ptr (ok), 12-Окт-26, 14:22
	> Оу. Ну, если у вас программисты "между нод" с tcpdump'ом ползают по > тому, что без этого никак-никак не разобраться что там и как > - то в этой консерватории очень-и-очень не так примерно ВСЁ. А если у Вас программисты в принципе не умеют пользоваться tcpdump, то это тем более ВСЁ )))
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	190. "-"	+/–
	Сообщение от User (??), 12-Окт-26, 15:38
	>> Оу. Ну, если у вас программисты "между нод" с tcpdump'ом ползают по >> тому, что без этого никак-никак не разобраться что там и как >> - то в этой консерватории очень-и-очень не так примерно ВСЁ. > А если у Вас программисты в принципе не умеют пользоваться tcpdump, то > это тем более ВСЁ ))) А других программистов у нас для вас - нет. И предполагаю, уже и не будет.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	193. "-"	+/–
	Сообщение от ptr (??), 12-Окт-26, 16:55
	>> А если у Вас программисты в принципе не умеют пользоваться tcpdump, то >> это тем более ВСЁ ))) > А других программистов у нас для вас - нет. И предполагаю, уже > и не будет. Я в курсе, так как системный интегратор, где я работаю, именно на таких клиентах и зарабатывает )))
	Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

	198. "-"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 18:12
	Зачем кому-то для низкоуровневой разработки брать гвидобейсик, если можно выучить нормальный язык? В любой низкоуровневой разработке все эти особенности среды выполнения всё равно не нужны.
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	200. "-"	+/–
	Сообщение от ptr (??), 12-Окт-26, 19:55
	> Зачем кому-то для низкоуровневой разработки брать гвидобейсик, если можно выучить нормальный > язык? В любой низкоуровневой разработке все эти особенности среды выполнения всё > равно не нужны. Даже для низкоуровневой разработки необходимы три языка: интерпретатор, компилируемый со сборщиком мусора и компилируемый с прямым управлением памяти. И если на ПК можно ещё как-то обойтись без интерпретатора, компилируя код на лету (на C# порой так и делаем), то как раз в низкоуровневой с этим куда сложнее.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "-"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 20:32
	>Даже для низкоуровневой разработки необходимы три языка: интерпретатор, компилируемый со сборщиком мусора и компилируемый с прямым управлением памяти. Зачем? Ладно в условные девяностые, когда ресурсов практически не было, но зачем сейчас нужен интерпретатор? Зачем нужен отдельный язык со сборщиком мусора, если уже сейчас идёт работа по автоматическому управлению памяти без сборщика мусора, без ручного выделения как в си, и без концепции владения как в rust?
	Ответить | Правка | Наверх | Cообщить модератору

	211. "-"	+/–
	Сообщение от ptr (??), 13-Окт-26, 00:12
	> Зачем? Ладно в условные девяностые, когда ресурсов практически не было, > но зачем сейчас нужен интерпретатор? Чтобы исполнять код, который неизвестен на момент написания программы. Если на том же C# эта проблема решается, например, RuntimeCompiler, то даже на достаточно мощных МК, компилятор не запустить. > Зачем нужен отдельный язык со сборщиком мусора, если > уже сейчас идёт работа по автоматическому управлению памяти без сборщика мусора, > без ручного выделения как в си, и без концепции владения как > в rust? C автоматическим управлением памятью без сборщика мусора? Если постараться натянуть сову на глобус, то такими языками можно считать Swift, Objective-C и другие языки с ARC. Но там тоже не всё так просто.
	Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

	225. "-"	+/–
	Сообщение от Аноним (66), 13-Окт-26, 12:44
	>Если на том же C# эта проблема решается, например, RuntimeCompiler, то даже на достаточно мощных МК, компилятор не запустить. Во-первых, с каких пор k8s соседствует с микроконтроллерами? Во-вторых, почему вместо того, чтобы прошить систему ОС, позволяющую запускать бинарники/загружать разделяемые библиотеки, вы тратите ресурсы на интерпретацию? >C автоматическим управлением памятью без сборщика мусора? Да, хотя они и экспериментальны. >то такими языками можно считать Swift, Objective-C и другие языки с ARC И тем не менее, обычных языков с GC вроде Golang или OCaml уже хватает для большого количества сценариев. Исключение разве что особо большие нагрузки. Зачем среднему проекту сразу три языка?
	Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

	139. "-"	+/–
	Сообщение от ptr (??), 11-Окт-26, 19:29
	> И c#. А на C# буквально в прошлом году интегрировались с PROFIBUS, где пришлось не только решать задачи с кодировками строк, но даже погружаться в числа дополнительном коде.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	142. "-"	+/–
	Сообщение от User (??), 11-Окт-26, 19:43
	>> И c#. > А на C# буквально в прошлом году интегрировались с PROFIBUS, где пришлось > не только решать задачи с кодировками строк, но даже погружаться в > числа дополнительном коде. "Ну как будто бы - осталось очень и очень немного причин"(Ц) С PROFIBUS не сталкивался - а вот со всякими MODBUS\OPC имеющиеся библиотеки на этот уровень сползать не заставляют.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "-"	+/–
	Сообщение от ptr (??), 11-Окт-26, 21:55
	> С PROFIBUS не сталкивался - а вот со всякими MODBUS\OPC имеющиеся библиотеки > на этот уровень сползать не заставляют. Скорее наоборот, там это сложнее, так как MODBUS не предоставляет возможности передачи текстовых сообщений. А в тех случаях, когда это нужно, и текстовые сообщения передаются через 16-битные регистры, я впервые слышу о системных библиотеках, которые решают эту задачу, позволяя выбрать нужную кодировку. Ссылочку можно?
	Ответить | Правка | Наверх | Cообщить модератору

	167. "-"	+/–
	Сообщение от User (??), 12-Окт-26, 08:18
	Не понимать. В opc ua utf8 строки кодируются в utf8 практически безальтернативно и разбирать их вручную при использовании какого-нибудь OPC UA .NET Client незачем. Преобразование с PLC в string делает UA server, преобразование из utf8 в utf16 от .net - прозрачно обеспечивает сам SDK. С modbus в этом смысле веселее - но нам easymodbus'овского ConvertRegistersToString хватило.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "-"	+/–
	Сообщение от ptr (??), 12-Окт-26, 10:05
	> Не понимать. В opc ua utf8 строки кодируются в utf8 В MODBUS нет строк, есть только дискретные (битовые) входы и выходы, а так же 16-битные входные и выходные регистры. Так что без демагогии, давайте про строки именнно MODBUS. > Преобразование с PLC в string делает UA server, Нет. От может разве что сопоставлять номера или фиксированные значения регистров со строками. А мы же говорим о случае, когда PLC должен выводить строку на индикатор. А кодировки знакогенераторов индикаторов даже в разных сериях одного продукта могут различаться.
	Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

	183. "-"	+/–
	Сообщение от User (??), 12-Окт-26, 12:30
	Не-не. Тут логически два разных варианта - один вот с opc ua клиент-сервер. Как сервер работает с PLC мне примерно по барабану - вот зона ответственности АСУ ТП. А между сервером и клиентом - ну, все просто. Второй - modbus с ConvertRegistersToString И нет, у меня задача не "вывести на индикатор", а "затащить телеметрию с устройства в бд с телеметрией" - в идеале вот вообще не общаясь с устройством, а через вооона тот OPC UA сервер.
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	188. "-"	+/–
	Сообщение от ptr (ok), 12-Окт-26, 14:25
	> Не-не. Тут логически два разных варианта - один вот с opc ua > клиент-сервер. Как сервер работает с PLC мне примерно по барабану - > вот зона ответственности АСУ ТП. А между сервером и клиентом - > ну, все просто. Как я указал, до тех пор, пока, для примера, не нужно выводить текст на индикатор. А тупой мэппинг номера регистров к константной строке явно не имеет отношения к обсуждаемой теме. Дальше будете отстаивать право на свою ограниченность? )))
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	189. "-"	+/–
	Сообщение от User (??), 12-Окт-26, 15:36
	>> Не-не. Тут логически два разных варианта - один вот с opc ua >> клиент-сервер. Как сервер работает с PLC мне примерно по барабану - >> вот зона ответственности АСУ ТП. А между сервером и клиентом - >> ну, все просто. > Как я указал, до тех пор, пока, для примера, не нужно выводить > текст на индикатор. А тупой мэппинг номера регистров к константной строке > явно не имеет отношения к обсуждаемой теме. > Дальше будете отстаивать право на свою ограниченность? ))) Нет, что вы? С почтением признаю полнейшую никчемность программистов, не способных с помощью осцилографа продиагностировать и с помощью паяльника починить возникающие в ходе эксплуатации кластера k8s проблемы. Бесперспективные вечные джуны, да.
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	194. "-"	+/–
	Сообщение от ptr (??), 12-Окт-26, 16:57
	>>> Как сервер работает с PLC мне примерно по барабану - >>> вот зона ответственности АСУ ТП. > Нет, что вы? С почтением признаю полнейшую никчемность программистов, не способных Не способных решить возникающие проблемы совместно с АСУ ТП, а не пытаясь переводить стрелки друг на друга. Что приводит к тому, что Ваше руководство вынуждено обращаться к системному интегратору в общем, а ко мне - в частности )))
	Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

	215. "-"	+/–
	Сообщение от User (??), 13-Окт-26, 07:26
	Оу. Не, ну если эти "программисты" еще и катриджи заправляют, витую пару тянут и другими "программистовскими" делами занимаются - то определенного клиента такой интегратор найдет, да-да.
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

	216. "-"	+/–
	Сообщение от ptr (ok), 13-Окт-26, 09:00
	>> Не способных решить возникающие проблемы совместно с АСУ ТП, >> а не пытаясь переводить стрелки друг на друга. > Оу. Не, ну если эти "программисты" еще и катриджи заправляют, витую пару То есть Вы даже не представляете себе иного пути решения проблемы, как сделать всё самому? )))
	Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

	217. "-"	+/–
	Сообщение от User (??), 13-Окт-26, 09:58
	>>> Не способных решить возникающие проблемы совместно с АСУ ТП, >>> а не пытаясь переводить стрелки друг на друга. >> Оу. Не, ну если эти "программисты" еще и катриджи заправляют, витую пару > То есть Вы даже не представляете себе иного пути решения проблемы, как > сделать всё самому? ))) Ну это у вас же программисты вот за dev'опсов с tcpdump'ом по облачному кубику ползают и за внедренцев\эксплуатационщиков с АСУТПшниками общаются - почему бы им вот еще и катриджи не позаправлять?
	Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

	218. "-"	+/–
	Сообщение от ptr (??), 13-Окт-26, 10:38
	>>>> Не способных решить возникающие проблемы совместно с АСУ ТП, >>>> а не пытаясь переводить стрелки друг на друга. >>> Оу. Не, ну если эти "программисты" еще и катриджи заправляют, витую пару >> То есть Вы даже не представляете себе иного пути решения проблемы, как >> сделать всё самому? ))) > Ну это у вас же программисты вот за dev'опсов с tcpdump'ом по > облачному кубику ползают и за внедренцев\эксплуатационщиков с АСУТПшниками общаются - > почему бы им вот еще и катриджи не позаправлять? Потому что локализация и диагностика проблемы, как это не удивительно для Вас, может выполняться разными специалистами. А если программист не знает, что принтер может плохо печатать из-за незаправленного картриджа, то и попросить заправить или заменить этот картридж он не сможет )))
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

	224. "-"	+/–
	Сообщение от Аноним (66), 13-Окт-26, 12:34
	>А если программист не знает, что принтер может плохо печатать из-за незаправленного картриджа, то и попросить заправить или заменить этот картридж он не сможет ))) А вы программисту за должность эникейщика доплачивать будете? Или наоборот, ищите программиста, готового работать за зарплату эникейщика? Каждый должен заниматься своей работой, если программист будет заправлять катриджи, то программировать он не будет. Какое дело программисту вообще до катриджей? Вы его попросите ещё пол в офисе мыть, и еду в столовой готовить.
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	243. "-"	+/–
	Сообщение от ptr (ok), 16-Окт-26, 08:54
	>>А если программист не знает, что принтер может плохо печатать из-за незаправленного картриджа, то и попросить заправить или заменить этот картридж он не сможет ))) > А вы программисту за должность эникейщика доплачивать будете? То есть в Вашем представлении совместная деятельность со смежником может заключаться исключительно в выполнении работы за этого смежника? )))
	Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

	227. "-"	+/–
	Сообщение от User (??), 13-Окт-26, 12:51
	Не-не-не. Вот как раз в моей картине мира - программисты - внезапно! программируют. Всё. А взаимодействием с АСУТП, эксплуатацией в кубике и ремонтом принтера занимаются немножко так другие люди. И нет, программисту - в принципе - вообще - ничего не надо знать про "катриджи", ему достаточно позвонить\написать: "Алё! тут принтер не работает!"
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	228. "-"	+/–
	Сообщение от ptr (??), 13-Окт-26, 13:08
	> И нет, программисту - в принципе - вообще > - ничего не надо знать про "катриджи", ему достаточно позвонить\написать: "Алё! > тут принтер не работает!" И это очень хорошо для системных интеграторов, так как работодатель таких программистов вынужден часть денежных средств, вместо зарплаты эти программистов, направлять в карман системных интеграторов, которые за услугу замены картриджа потребуют десятикратную стоимость этого картриджа ))) Аналогично и с коммуникацией между программистами и АСУ ТП. Если сотрудники не могут работать совместно и разговаривать на одном языке, а могут лишь переводить стрелки друг на друга, то они, по сути, так и остаются в статусе джунов с соответствующей зарплатой, не способных решать проблемы самостоятельно. Задумайтесь о том, почему у Вас такая зарплата и как это связано с Вашей позицией по отношению к смежникам. Я в РФ не видел работников даже с 300К зарплатой и такой позицией. Не говоря уже о 500К и выше.
	Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

	230. "-"	+/–
	Сообщение от User (??), 13-Окт-26, 13:40
	Ооооо, в дискуссии в интернете речь пошла про зарплаты! Снимайте шляпы - интеграторы в треде! Только сегодня, только сейчас, только у нас и только для вас - программисты готовы диагностировать проблемы python-софта в kubernetes с помощью tcpdump мигая при этом индикатором! Дорого.
	Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

	234. "-"	+/–
	Сообщение от ptr (??), 13-Окт-26, 15:14
	> Только сегодня, только сейчас, только у нас и только для вас - > программисты готовы диагностировать проблемы python-софта в kubernetes с помощью tcpdump > мигая при этом индикатором! Дорого. Из моего опыта, например, был виноват принтер из-за кривой генерации PostScript программистом, что выяснилось только после того, как за обслуживание принтера заплатили больше $1000 )))
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	235. "-"	+/–
	Сообщение от User (??), 13-Окт-26, 15:48
	>> Только сегодня, только сейчас, только у нас и только для вас - >> программисты готовы диагностировать проблемы python-софта в kubernetes с помощью tcpdump >> мигая при этом индикатором! Дорого. > Из моего опыта, например, был виноват принтер из-за кривой генерации PostScript программистом, > что выяснилось только после того, как за обслуживание принтера заплатили больше > $1000 ))) Ненене. Я понимаю, что "программист"(ТМ) может копать - может не копать, но я сварщик не настоящий и КМТ диагностировать пока еще не готовый.
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	120. "-"	+/–
	Сообщение от Аноним (45), 11-Окт-26, 12:30
	>> Строка - это массив символов. > А символ - это массив байтов. Из чего получаем, что строка - это тоже массив байтов. А символ, о мой пытающийся в софистику, но лишь облагораживающий лужу опеннетный друк - может кодироваться одним байтом. Или несколькими. В зависимости от кодировки. Т.е. оно не ложиться 1:1 на массив байт, хоть ты тресни. Из чего получаем, что память, это конечно массив байт, но третим симвлом строки char* str[3] может и не быть. И для _гарантированного_ получения третьего символа строки в кодировке UTF-8 нам придется пройтись по "массиву" с самого начала. Хотя вроде как основным качеством массива является произвольный доступ к хранимому элементу через индекс, с выч. сложностью О(1), а совсем не О(n)  ... и в каком месте это тогда массив, а не _список_ байтов? >> если пытаться работать с ним как с массивом байт > Назовите мне хотя бы одну машинную команду любой архитектуры, умеющую работать с символами UTF-8, а не байтами. Т.е. сам же пишешь, что машины с UTF-8 работать не умеют, только с байтами. Но удивляешься заявлению, что погроммист не должен (пытаться) работать с UTF-8, как с массивом байтов 🤦 > Другой вопрос, что у программиста всегда есть возможность воспользоваться готовым кодом, > работающим с массивом байтов, но предоставляющим в интерфейсе абстракции для массивов символов. Занимательная (нет) софистика, но ... как только погроммист начинает использовать абстракции для работы с массивом символов, он (внезапно) перестает работать с ним, как c массивом байт. Сама абстракция кстати тоже - потому что главная фишка массива, доступ к его элементу (т.е. хранимому символу) по индексу, без дополнительной иформации о строке - превращается в тыкву.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	133. "-"	+/–
	Сообщение от ptr (??), 11-Окт-26, 17:08
	>>> Строка - это массив символов. >> А символ - это массив байтов. Из чего получаем, что строка - это тоже массив байтов. > может кодироваться одним байтом. Или несколькими. Массив так же может быть из одного байта. Или нескольких. > оно не ложиться 1:1 на массив байт А вот это уже подмена тезиса и демагогия, так Вы сейчас оспариваете утверждение, которое сами же придумали ))) >>> если пытаться работать с ним как с массивом байт >> Назовите мне хотя бы одну машинную команду любой архитектуры, умеющую работать с символами UTF-8, а не байтами. > Т.е. сам же пишешь, что машины с UTF-8 работать не умеют, только > с байтами. Но удивляешься заявлению, что погроммист не должен (пытаться) работать > с UTF-8, как с массивом байтов 🤦 Наоборот, утверждаю, что программист должен понимать, что работа со строкой символов на уровне машинных команд сводится к работе с массивом байтов.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "-"	+/–
	Сообщение от iZEN (ok), 10-Окт-26, 18:51
	В сишке строка — это указатель на структуру в памяти. В Паскале строка — это байтовый массив, в нулевом байте которого находится число, указывающее длину строки. В Java строка — это ссылка на объект в памяти.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	97. "-"	+/–
	Сообщение от Аноним (95), 11-Окт-26, 05:02
	Открою тебе страшную тайну. >В Паскале строка — это байтовый массив, в нулевом байте которого находится число, указывающее длину строки. В Линуксе файловая система отдельно хранит количество и длинну строк. >В Java строка — это ссылка на объект в памяти. Но мы то знаем, что за объектами скрывается процедурный код.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "-"	–1 +/–
	Сообщение от Аноним (66), 10-Окт-26, 19:51
	Почему это строка должна быть массивом? Почему она не может быть списком массивов, или деревом массивов? Во-вторых, с чего вы взяли, что произвольный двоичный поток байтов - это строка? Вот "h\0e\0l\0l\ow" - это строка или не строка? Что насчёт управляющих символов? Почему вы считаете, что это массив, если кодировка не имеет фиксированной длины?
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	99. "-"	+1 +/–
	Сообщение от _ (??), 11-Окт-26, 05:11
	> Почему это строка должна быть массивом? Не должна. Впрочем всё в мире относительно, в памяти всё - есть "кучки байт"(С)
	Ответить | Правка | Наверх | Cообщить модератору

	112. "-"	+/–
	Сообщение от iZEN (ok), 11-Окт-26, 10:14
	> Почему это строка должна быть массивом? Потому что, очевидно, так легче хранить и интерпретировать. Особенно это прослеживается в процедурных ЯВУ. > Почему она не может быть списком массивов, или деревом массивов? Потому что для этого (обхода списка массива или дерева) потребуется написать тонну дополнительного кода вместо простого цикла со счётчиком. Простая строка превращается в объект в объектно-ориентированных языках программирования для более экономного расходования оперативной памяти (например, в общем пуле строк), но при этом необходимо обеспечить доступ к этому пулу, математику хэширования одинаковых строк или их фрагментов на уровне компилятора и обход-перечисление всех "букв"-символов в каждой строке.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	29. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от User (??), 10-Окт-26, 16:07
	Ну, пожалуй что спорить и не буду, хорошо. И что "позади" - хорошо, и что "отмирают" - замечательно. Но в общем-то "были" и вполне объективно пенять змеюке что в 2008 гвоздями не приколотили я, пожалуй, не буду - там и без того весело было.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	35. "Выпуск языка программирования Python 3.15"	–3 +/–
	Сообщение от Аноним (35), 10-Окт-26, 17:43
	>Вот ещё потихоньку отмирают сишные динозавры с мантрой "строка - это массив байт", забирая с собой целую эпоху уязвимостей. "Пользуясь случаем обосру ка я Си". Ничего у тебя не получится. Объективно конкурента чистому Си нет. Си и железо, как муж и жена, просто by design. Человек пишуший на низком уровне поймёт эту аналогию. Rust же настолько развит, что составляет конкуренцию, такому же развитому языку, как C++.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	50. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от iZEN (ok), 10-Окт-26, 19:01
	>>Вот ещё потихоньку отмирают сишные динозавры с мантрой "строка - это массив байт", забирая с собой целую эпоху уязвимостей. > Объективно конкурента чистому Си нет. Си и железо, как муж и жена, > просто by design. Человек пишуший на низком уровне поймёт эту аналогию. А как же Lisp, Forth, проект Lilith, picoJava?
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Выпуск языка программирования Python 3.15"	–1 +/–
	Сообщение от Аноним (69), 10-Окт-26, 20:15
	>А как же Lisp Запомни, Лисп без Лисп-машины - ничто. Лисп, как язык, по настоящему низкоуровневым может быть только на Лисп-машине. >проект Lilith ПК от покойного Никлауса Вирта? Швейцарская промышленность не заинтересовалась. Спроса нету. Швейцария не Китай. Удел Китая быть штамповкой для всего мира. >Forth, picoJava? Не знаю. Что-то экзотическое?
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от _ (??), 11-Окт-26, 05:12
	> А как же Lisp, Forth, проект Lilith, picoJava? Где они все напоминать надо? И как давно они там тоже?
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	67. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Аноним (66), 10-Окт-26, 20:11
	>Rust же настолько развит, что составляет конкуренцию, такому же развитому языку, как C++. Давно в Linux c++ приняли?
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	86. "Выпуск языка программирования Python 3.15"	+2 +/–
	Сообщение от Аноним (86), 10-Окт-26, 23:21
	Чл хвалит пистон и обсирает Си, на котором этот самый кривой пистон и написан.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	191. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (191), 12-Окт-26, 16:16
	> Си и железо, как муж и жена, просто by design. Человек пишуший на низком уровне поймёт эту аналогию. Ты там не из 1970-х пишешь? Потому что то что делает железо уже много десятков лет не напоминает исходный Си код от слова совсем. И даже дизасм x86 не напоминает. Вообще глупо размышлять о дизайне железа с точки зрения авторов таких перлов как strtok, которые даже многопроцессорность не смогли вообразить.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	213. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (213), 13-Окт-26, 07:14
	>Ты там не из 1970-х пишешь? А какая разница чисты Си вечнозелёный язык. >Потому что то что делает железо уже много десятков лет не напоминает исходный Си То что делает железо напоминает GNU assembler. А чистый Си макисмально приближен к архитектуре железа. Что не так? >Вообще глупо размышлять о дизайне железа с точки зрения авторов таких перлов как strtok Алень, зачем ты от простой библиотеки требуешь встроенной многопоточности?  Всегда были POSIX треды или ты не осилил их?
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 13-Окт-26, 12:50
	>То что делает железо напоминает GNU assembler. Вот именно, что напоминает. >А чистый Си макисмально приближен к архитектуре железа. Что не так? То, что си никогда не был переносим. Вот типичный пример сишного кода https://www.opennet.ru/openforum/vsluhforumID3/141671.html#191 >2. Да, это было "приятным" сюрпризом понять что мои оптимизации вида: нафига нам тут memcmp(), просто сравним два uint32_t - нам ведь всего 4 байта сранить надо! испортили дело :) Сишный код слабо переносим как между архитектурами, так и между компиляторами, и если сишный код скомпилировался, то это ещё не значит, что он будет правильно работать.
	Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск языка программирования Python 3.15"	+7 +/–
Сообщение от Ivan_83 (ok), 10-Окт-26, 13:49
> Добавлена встроенная игра с текстовым интерфейсом Ну вот и стало понятно куда оно дальше будет расти. Потом дюкнюхема встроят и надо будет бегать баги отсреливать, потом ещё чтонить из квейка, поле непаханное для прогресса ЯП!
Ответить | Правка | Наверх | Cообщить модератору

	5. "Выпуск языка программирования Python 3.15"	+3 +/–
	Сообщение от Ivan_83 (ok), 10-Окт-26, 13:49
	Но следующей должна быть змейка, как же без этого :)
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (9), 10-Окт-26, 14:35
	А потом Doom?
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от BrainFucker (ok), 10-Окт-26, 14:43
	Было такое выражение doom scrolling, а это будет doom coding.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от ХрюХрю (?), 10-Окт-26, 18:35
	потом тетрис
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	91. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (91), 11-Окт-26, 02:34
	Ну это уже когда оптимизации пойдут
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от BrainFucker (ok), 10-Окт-26, 14:42
	Кстати, в советских игровых автоматах вроде как эту игру именно Питоном называли.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	55. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Инопланетянин (?), 10-Окт-26, 19:45
	> Но следующей должна быть змейка, как же без этого :) На больших уровнях будет тормозить же.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	46. "Выпуск языка программирования Python 3.15"	–2 +/–
	Сообщение от Я (??), 10-Окт-26, 18:49
	А зачем ещё кампуктер нужен нормальному человеку дома?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	64. "Выпуск языка программирования Python 3.15"	–1 +/–
	Сообщение от Инопланетянин (?), 10-Окт-26, 20:00
	>> Добавлена встроенная игра с текстовым интерфейсом > Потом дюкнюхема встроят Ньюка не трож, революционная игра для своего времени. Соврменные питонщики даже с безлимитом токенов такого бы не сделали.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	80. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Аноним (80), 10-Окт-26, 22:16
	Потом встроят ИИ прямо вы интерпретатор и он бует работать локально.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

10. "Выпуск языка программирования Python 3.15"	–4 +/–
Сообщение от inferrna (ok), 10-Окт-26, 14:41
Версию 3.16 перепишут с нуля на расте. Запомните этот твит.
Ответить | Правка | Наверх | Cообщить модератору

	21. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от dannyD (?), 10-Окт-26, 15:26
	ты забыл указать "кто" - m$ )))
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (24), 10-Окт-26, 15:46
	Тем кто пишет на C++ биндинги что на раст, что на жутком си - всё едино.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	27. "Выпуск языка программирования Python 3.15"	+3 +/–
	Сообщение от пох.. (?), 10-Окт-26, 15:55
	начнут переписывать. Но дальше CoC.md не уйдут.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	37. "Выпуск языка программирования Python 3.15"	+4 +/–
	Сообщение от xPhoenix (ok), 10-Окт-26, 18:09
	Скорей бы. О, сколько нас открытий чудных ждёт, когда код CPython как следует начнут пентестить...
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	61. "Выпуск языка программирования Python 3.15"	–2 +/–
	Сообщение от Инопланетянин (?), 10-Окт-26, 19:57
	> Версию 3.16 перепишут с нуля на расте. > Запомните этот твит. Если станет быстрее, то пусть. Но он не станет. Проблемы в дизайне языка и разрабах, которые заняты всем чем угодно, кроме решения проблемы производительности. Нужно просто взять pypy и назвать это питон 3.17.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	68. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 10-Окт-26, 20:12
	>Нужно просто взять pypy Достаточно выкинуть питон целиком, включая pypy, как сразу же и потребление памяти улучшится, и скорость.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от _ (??), 11-Окт-26, 05:16
	Мы это сделали во времена Py2-->Py3 - брат жив и даже ушицу жрёт :)
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от User (??), 11-Окт-26, 08:23
	Мне даже интересно, что взяли на замену? Не, сейчас-то ясно-понятно, а вот в 2009 примерно?
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от _ (??), 12-Окт-26, 00:17
	Сидели на втором до упора вестимо, сами патчи писали и вот это вот всё... Но параллельно разные куски переписывали на разном... Виндовая часть оказалась самой простой - она вся целиком ушла на шарп. Иногда даже завидую вантузятникам, да. :) А вот с линуксовой было труднее, там много чего происходило... хороший кусок в конце концов переделали на Go, но увы - не только на него, плюсы к примеру тоже есть ну и JS, как жи без него, но оно в веб морде, я про это и при желании много рассказать не cмогу. Как оно сейчас я не знаю, продукт жив, но уже дважды собственник сменился :-/ ... причём нонешний - китайцы прикидывавшиеся омереганцами, житие моё... эти могут питон и заново внести :) PS: красные ящички, но на этом - всё!, сорян ;)
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от User (??), 12-Окт-26, 07:16
	Ну, вариант "сидим на двойке, а потом переходим на go" вполне себе вариант ). Я вот даже переходивцев-на-groovy видел, и это был интересный опыт :)
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Выпуск языка программирования Python 3.15"	+2 +/–
	Сообщение от Аноним324 (ok), 11-Окт-26, 06:32
	Но у питона не проблем с производительностью, по меркам интерпретаторов он достаточно быстрый, а по меркам живых интерпретаторов, так вообще ракета, ведь существует ещё руби.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	108. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от User (??), 11-Окт-26, 08:25
	Ну, у меня для вас джве плохие новости: 1. Ruby не то, чтобы сильно "живой" 2. Он быстрее змеюки. Заметно.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним324 (ok), 11-Окт-26, 09:50
	> Ну, у меня для вас джве плохие новости: > 1. Ruby не то, чтобы сильно "живой" Вполне живой, новые проекты есть, работа есть, brew в макоси никуда не делся. Мёртвый он у тех, у кого и пхп мёртв, а когда заходишь на сайты по поиску работы, там этой работы выше крыши на любой вкус, цвет и бюджет.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от User (??), 11-Окт-26, 10:06
	>> Ну, у меня для вас джве плохие новости: >> 1. Ruby не то, чтобы сильно "живой" > Вполне живой, новые проекты есть, работа есть, brew в макоси никуда не > делся. Мёртвый он у тех, у кого и пхп мёртв, а > когда заходишь на сайты по поиску работы, там этой работы выше > крыши на любой вкус, цвет и бюджет. Ну ок. Что я, спорить буду? Нет, не буду :). В родственниках вот и вовсе - программист на "живом" 1C 7.7 с работой и при деньгах имеется ).
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (219), 13-Окт-26, 10:51
	> разрабах, которые заняты всем чем угодно, кроме решения проблемы производительности Над проблемой производительности как раз усердно работают. В том числе microsoft.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	236. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Инопланетянин (?), 13-Окт-26, 15:55
	>> разрабах, которые заняты всем чем угодно, кроме решения проблемы производительности > Над проблемой производительности как раз усердно работают. В том числе microsoft. Это где уволили команду по ускорению питона? > В мае 2025 года Microsoft полностью свернула поддержку проекта Faster CPython и распустила команду разработчиков, занимавшуюся оптимизацией производительности языка Python
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Инопланетянин (?), 13-Окт-26, 15:58
	>> разрабах, которые заняты всем чем угодно, кроме решения проблемы производительности > Над проблемой производительности как раз усердно работают. Могут хоть трижды усердно работать. Где результат? pypy его дал, v8 дал, luajit в лице одного разработчика дал. Тут его нет. Есть мифифческие: перепишем новый сборщик, которые позволит сделать оптимизации... хочется добавить "но это не точно". К слову jit вообще хотели удалить в питоне. Да, тот самый которые еще не сделали.
	Ответить | Правка | К родителю #219 | Наверх | Cообщить модератору

	92. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (91), 11-Окт-26, 02:35
	Поэтому все вернутся на 3.14, наступит так сказать 3.14, и станет хорошо. Да?
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	179. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от _kp (ok), 12-Окт-26, 12:06
	В смысле вернутся на 3.14? Её же так и "вышла". Её не доделали, умерла так и не став годной для использования. Версия 3.14 с чем только не совместима, и любое решение - только выкинуть, и поставить постарее. В том числе для модного ИИ. :) Значительную часть ПО на Питоне - хрен запустишь на версии 3.14. И в заключении о хорошем. Питон 3.14 теперь можно смело хоронить. И несовместимый и устаревший.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Frestein (ok), 13-Окт-26, 13:14
	Кроме гонения воздуха какие-то реальные примеры привести способны?
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от _kp (ok), 13-Окт-26, 14:32
	Не секрет, что Питон  имеет АД зависимостей и имеет совместимости с предыдущими версиями. Из за этого, на Pytnon 3.14 не удалось перекомпилировать часть библиотек, без которых он не имеет смысла. И в итоге вернулся к предыдущим версиям. Здесь, упомянута аналогична проблема, с перекомпиляций других библиотек. Но, здесь то хоть "альфа версия" очередного Pytnon. А инстументы для Pytnon 3.14 так и не довели до годного состояния.
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Frestein (ok), 17-Окт-26, 11:59
	Так и в чём проблема? Выход 3.15 не хоронит все предыдущие релизы. 3.10 продолжает обновляться.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Hexen (ok), 11-Окт-26, 19:16
	А зачем переписывать Python на Rust когда можно сразу на Rust писать? А тем кому нужно быстро разрабатывать могут вайбкодить на Rust)
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	174. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (3), 12-Окт-26, 11:44
	Нет, пока не смогли переписать даже такую банальщину как perl, php, pascal, basic - куда им до бидона. Тем более что у него теперь через версию всякие разные breaking changes от которых у ИИ рвёт шаблоны и контекст
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

12. "Выпуск языка программирования Python 3.15"	–6 +/–
Сообщение от BrainFucker (ok), 10-Окт-26, 14:43
А для кого новый синтаксический сахар в язык сейчас добавляют, если руками мало кто теперь будет кодить?
Ответить | Правка | Наверх | Cообщить модератору

	62. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Инопланетянин (?), 10-Окт-26, 19:57
	> А для кого новый синтаксический сахар в язык сейчас добавляют, если руками мало кто теперь будет кодить? Очевидно для уменьшения контекста и расхода токенов.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Выпуск языка программирования Python 3.15"	–2 +/–
	Сообщение от BrainFucker (ok), 10-Окт-26, 21:35
	Экономия на спичках. Можно тогда код обфусцировать или сразу на ассемблере генерить.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Инопланетянин (?), 10-Окт-26, 22:24
	> Можно тогда код обфусцировать Как обфускация поможет? Если сокращение идентификаторов, то смысла нет. Если запутывание, то еще хуже будет. > или сразу на ассемблере генерить. Ассемблер наоборот слишком многословный и нетипизированный.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Инопланетянин (?), 10-Окт-26, 22:26
	> Экономия на спичках. Можно тогда код обфусцировать или сразу на ассемблере генерить. В целом это больше шутка была. Но изменения синтаксиса для облегчения работы LLM делают, например, в moonbit. Там даже исследования есть.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	70. "Выпуск языка программирования Python 3.15"	+3 +/–
	Сообщение от limafresh (ok), 10-Окт-26, 20:26
	Для тех, кто будет кодить руками.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	76. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от BrainFucker (ok), 10-Окт-26, 21:37
	Это становится невыносимым, после вайбкода ощущение будто в песочнице в куличики играешь.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от _ (??), 11-Окт-26, 05:20
	Мне наши прогеры тоже подобное высказали :( Всё таки я думаю я прав, заявляя что программирование на ЯП - всио!
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (3), 12-Окт-26, 11:47
	Глядя на то как общее количество людей затянутых в вайти продолжает расти, а квалификация вайбкодеров падает шустрее чем у веббауинов... могу сказать что вас из разработки "всио" будет сильно быстрее чем программирование на ЯП
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от анонимс (?), 11-Окт-26, 20:26
	Так мир программирования и разделится на дешёвых вайберов коих как пыли и дорогих инженеров поддерживающих инфстрастуктуру
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	145. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от BrainFucker (ok), 11-Окт-26, 20:28
	А эти инфраструктуры сейчас с вами в одной комнате?
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (219), 13-Окт-26, 10:52
	Да, в одной. Ещё вопросы?
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от _ (??), 12-Окт-26, 00:50
	> Так мир программирования и разделится на дешёвых вайберов коих как пыли и дорогих инженеров поддерживающих инфстрастуктуру Блажен кто верует!(С) "инженеров поддерживающих инфстрастуктуру" осталось только в виде ансибельщикофф(С) и тераформщекофф(С) поддерживающих клауд. И тут сюрприз(!) - ЫЫ и в терраформ и в ансиблячьи роли и плеи уже запросто умеет, умеет очччень не плохо, не хуже кожаных уж точно! Если делаешь новый проект, то знай - первоначальную рыбу архитектуры проекта тоже нынче делает ЫЫ-ка, собирает все хотелки, доку, рестрикшены и пр. блупапиры ... и делает! Даже либы подбирает! Я ж писал - из нескольких этажей девелоперс!(С) остался лишь угол на одном. Прогресс!(С)
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	176. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (3), 12-Окт-26, 11:54
	Почему-то те кто так заявляет, когда я к ним прихожу и спрашиваю как это юзать в проекте вот прям сейчас - ручки бантиком, ножки домиком... и нифига не готово. Я так уже третий месяц инстанс n8n жду, потому что делать просто, как уже готово работать здесь и сейчас через пару вызовов API и пайплайна - сказали что "не современно"
	Ответить | Правка | Наверх | Cообщить модератору

	212. Скрыто модератором	+/–
	Сообщение от _ (??), 13-Окт-26, 04:18
	... и чо? У кожаных так не было? Престиж IT скоро сравняется с престижем доставщика пиццы, а зарплата сядет даже ниже - если верить официальным угрозам Илона нашего Маска :-D
	Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Ivan_83 (ok), 10-Окт-26, 14:50
> Добавлено ключевое слово "lazy" для отложенной загрузки модулей, при помощи которой можно ускорить запуск приложений с большим числом зависимостей. Лучше бы они сделали delay multithread загрузку. Типа приложение стартонуло а потом в отдельных потоках оно эти ненужноимпорты подтягивает чтобы когда они потребуются - уже были. С lazy это будет постоянное лагалово в непредсказуемых местах.
Ответить | Правка | Наверх | Cообщить модератору

	17. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (17), 10-Окт-26, 15:02
	Пока не смотрел на 3.15, но вангану еще бОльшую проблему. Если раньше ошибка импорта была в начале загрузки модуля, то теперь ее надо будет ловить в непредсказуемом месте.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Ivan_83 (ok), 10-Окт-26, 15:08
	Я не пишу на питоне но у нас в продукте проблема с тем что импорт подгружает биндинг к С либе очень долго, при этом далеко не всегда к этому биндингу обращаются сразу после реалоада воркера.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Выпуск языка программирования Python 3.15"	–2 +/–
	Сообщение от Аноним (151), 11-Окт-26, 21:24
	> импорт подгружает биндинг к С либе это все, что нужно знать о твоей компетенции
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от User (??), 10-Окт-26, 15:12
	а в новость смотрел? "В случае проблем с загрузкой модуля, например, если модуль не найден, исключение генерируется в момент попытки первого использования, а не во время импорта. Для принудительного отключения отложенной загрузки предусмотрена опция командной строки "-X lazy_imports" и переменная окружения PYTHON_LAZY_IMPORTS"(Ц)
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	116. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от iZEN (ok), 11-Окт-26, 10:24
	Вчера вечером на домашнем десктопе перешёл с Python3.14 на Python3.15 с перекомпиляцией всего и вся от него зависящего. Споткнулся на компиляции qt6-base и иже с ней: ===>  Configuring for py315-spdx-tools-0.8.5_1 ===>  Building for py315-spdx-tools-0.8.5_1 /usr/bin/env -i PYTHONPATH=/usr/ports/misc/py-spdx-tools/work-py315/spdx_tools-0.8.5/src:/usr/local/lib/python3.15 /usr/local/bin/python3.15 /usr/ports/misc/py-spdx-tools/files/generate-parsetag.py Traceback (most recent call last):   File "/usr/ports/misc/py-spdx-tools/files/generate-parsetag.py", line 7, in <module>     import spdx_tools.spdx.parser.tagvalue.tagvalue_parser as tvp   File "/usr/ports/misc/py-spdx-tools/work-py315/spdx_tools-0.8.5/src/spdx_tools/spdx/parser/tagvalue/tagvalue_parser.py", line 4, in <module>     from spdx_tools.spdx.model import Document   File "/usr/ports/misc/py-spdx-tools/work-py315/spdx_tools-0.8.5/src/spdx_tools/spdx/model/__init__.py", line 7, in <module>     from spdx_tools.spdx.model.actor import Actor, ActorType   File "/usr/ports/misc/py-spdx-tools/work-py315/spdx_tools-0.8.5/src/spdx_tools/spdx/model/actor.py", line 6, in <module>     from beartype.typing import Optional   File "/usr/local/lib/python3.15/site-packages/beartype/__init__.py", line 150, in <module>     _init()     ~~~~~^^   File "/usr/local/lib/python3.15/site-packages/beartype/__init__.py", line 71, in _init     from beartype.meta import (     ...<4 lines>...     )   File "/usr/local/lib/python3.15/site-packages/beartype/meta.py", line 33, in <module>     from beartype._util.text.utiltextversion import (         convert_str_version_to_tuple as _convert_str_version_to_tuple)   File "/usr/local/lib/python3.15/site-packages/beartype/_util/text/utiltextversion.py", line 15, in <module>     from beartype.typing import Tuple   File "/usr/local/lib/python3.15/site-packages/beartype/typing/__init__.py", line 183, in <module>     from typing import (     ...<35 lines>...     ) ImportError: cannot import name 'no_type_check_decorator' from 'typing' (/usr/local/lib/python3.15/typing.py) *** Error code 1 Stop. make[1]: stopped making "/usr/ports/misc/py-spdx-tools/work-py315/.stage_done.spdx-tools._usr_local" in /usr/ports/misc/py-spdx-tools *** Error code 1 Stop. make: stopped making "all" in /usr/ports/misc/py-spdx-tools
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	123. "Выпуск языка программирования Python 3.15"	+3 +/–
	Сообщение от Ivan_83 (ok), 11-Окт-26, 14:07
	Фиг знает зачем вам 3.15 на фре то. У меня 3.13 и то он не дефолтный, и только потому что для хом асистанта нужен, а так то мне плевать на то какой питон в системе и есть ли он там вообще. (лучше бы не было, как и перла и много чего ещё)
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от iZEN (ok), 11-Окт-26, 16:22
	DEFAULT_VERSIONS+=perl=5.44 perl5=5.44 DEFAULT_VERSIONS+= python=3.15 python3=3.15 DEFAULT_VERSIONS+=gcc=16 DEFAULT_VERSIONS+=qt=6 DEFAULT_VERSIONS+=llvm=22 в /etc/make.conf.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Ivan_83 (ok), 11-Окт-26, 16:37
	python3 уже не обрабатывается насколько я знаю для это переменной. # Ports defaults DEFAULT_VERSIONS+=ccache=ccache-devel DEFAULT_VERSIONS+=librsvg2=legacy DEFAULT_VERSIONS+=mysql=10.11m DEFAULT_VERSIONS+=perl5=5.42 DEFAULT_VERSIONS+=php=83 DEFAULT_VERSIONS+=python=3.13 DEFAULT_VERSIONS+=ssl=base # libressl: dropped since 2024.01.01 due to require too many time to support.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от _kp (ok), 12-Окт-26, 12:13
	>> перешёл с Python3.14 на Python3.15 Более странно, что Вы с Python3.14 вообще работали, или допинали его до годного состояния. Ибо и под 3.14 много что не перекомпилировалось, и приходилось от "бета версии" отказываться.
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	204. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от iZEN (ok), 12-Окт-26, 21:34
	На 3.14 у меня всё собиралось. Не испытывал никаких проблем. Даже кольцевые зависимости нескольких пакетов с glib решаются. С 3.15 не собираются: qt6-*/ kf6-* и firefox/thunderbird.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от _kp (ok), 13-Окт-26, 12:22
	У меня на 3.14 не собирались из за ада зависимрсткй и несовместимостей ИИ библиотеки. Плюнул, откатил на 3.12 где все работает из коробеки.
	Ответить | Правка | Наверх | Cообщить модератору

22. "Выпуск языка программирования Python 3.15"	–3 +/–
Сообщение от Аноним (22), 10-Окт-26, 15:32
>После года разработки опубликован значительный выпуск языка программирования Python 3.15. Среди изменений: включение по умолчанию UTF-8 Питонщики чо за хрень. 2026 год твою мать. Юникод давно стандарт.
Ответить | Правка | Наверх | Cообщить модератору

	31. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (45), 10-Окт-26, 16:15
	>> Python now uses UTF-8 as the default encoding, independent of the system’s environment. This means that I/O operations without an explicit encoding, > Питонщики чо за хрень. 2026 год твою мать. Юникод давно стандарт. Эт да, считать что если юзверь выставил что-то другое, то он наверное лучше знает что ему нужно и его не обязательно осчастлививать прогрессом ... ну что со старых прдунов-лдиттов взять? Хорошо что их ушли - прогресс теперь будет семимильными шагами скакать! Хотя ж все таки недоработочка: > To retain the previous behaviour, Python’s UTF-8 mode may be disabled with the > PYTHONUTF8=0 environment variable or the -X utf8=0 command-line option. Зачем эти ненужные компромиссы? Пущай лучше все свои скрипты правят с явным указанием кодировки!
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (-), 11-Окт-26, 16:37
	> Эт да, считать что если юзверь выставил что-то другое, то он наверное лучше знает что ему нужно и его не обязательно осчастлививать прогрессом Юзверь выставил что-то другое в основном для ввода-вывода в консоль. Пусть хоть шифтжис выставляет. Принты работают (ну кроме случаев, когда не работают), все счастливы. Но есть другой сценарий: скрипт пишет в файл, кодировку разработчик указать забывает - зачем ему? у него линукс, там utf-8 у всех нормальных людей. Все хорошо, пока скрипт не запускают на винде, которая читает из этого файла уже 1251. Так то да, > Пущай лучше все свои скрипты правят с явным указанием кодировки! если хотят чего-то нестандартного. А самое главное, что принты-то продолжают работать, потому что даже с PYTHONUTF8 у PYTHONIOENCODING приоритет.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от User (??), 11-Окт-26, 19:36
	>> Эт да, считать что если юзверь выставил что-то другое, то он наверное лучше знает что ему нужно и его не обязательно осчастлививать прогрессом > Юзверь выставил что-то другое в основном для ввода-вывода в консоль. Пусть хоть > шифтжис выставляет. Принты работают (ну кроме случаев, когда не работают), все > счастливы. Ммммм... скорее нет, там с 3.6 примерно дефолтный вывод в консоль даже на поганой в utf8. И кодировка самих скриптов в нем же без coding: задефолтена. > Но есть другой сценарий: скрипт пишет в файл, кодировку разработчик указать забывает > - зачем ему? у него линукс, там utf-8 у всех нормальных > людей. Все хорошо, пока скрипт не запускают на винде, которая читает > из этого файла уже 1251. Так то да, А вот тут бинго. Практически последний реальный кейс.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (3), 12-Окт-26, 12:03
	юзверь "выставил" что-то другое, но только сам не выставлял. Поэтому в фортках в cmd вывалит cp866, в powershell cp1251, но тебе нужно поработать с нормальным документом который "просто должен открываться одинаково у всех" и... дальше, совершенно внезапно, выясняется что приседания с chcp 65001 и $OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = [System.Text.UTF8Encoding]::new() работают не везде, а когда работают - с UTF-8 не справляется часть стандартных утилит и пайплайны превращаются просто в месиво. Про сохранить color output в консоли даже речи нет. Просто всё в фарш.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	38. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (38), 10-Окт-26, 18:15
	Ага, особенно в Си и С++
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

59. "Выпуск языка программирования Python 3.15"	+2 +/–
Сообщение от Инопланетянин (?), 10-Окт-26, 19:53
Ускоряют, что-то ворочают jit, а как был медленный так и оставлся. Сторонний pypy показывает куда более значимые результаты, притом пилится гораздо меньшим кол-вом люлей. Думайте!
Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Инопланетянин (?), 10-Окт-26, 19:54
> В модуле typing расширены возможности аннотирования типов при помощи классов TypedDict и TypeForm Скоро по определениям типов переплюнет шаблоны в плюсах, только скорости это не добавит.
Ответить | Правка | Наверх | Cообщить модератору

	72. "Выпуск языка программирования Python 3.15"	+2 +/–
	Сообщение от Аноним (72), 10-Окт-26, 20:35
	Даст возможность почувствовать себя плюсовиком, чем настоящие питоничные питонисты и пользуются.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Инопланетянин (?), 11-Окт-26, 20:48
	> Даст возможность почувствовать себя плюсовиком Зачем?
	Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Аноним (66), 10-Окт-26, 20:08
>который теперь позволяет добиться в среднем ускорения на 11-12% на платформе macOS AArch64 и на 7-8% на платформе x86_64 Linux в тестах pyperformance по сравнению со стандартным интерпретатором Гвидобейсик нужно не ускорять, а выкидывать, и писать на изначально быстрых языках программирования. Это же нужно было так суметь создать язык программирования, который не смотря на весь влитый в него капитал умудряется стабильно оставаться на дне, по сравнению с остальными популярными языками. Такой уровень производительности допустим разве что на стадии прототипирования/написания студентами. >При этом в отдельных тестах при включении JIT изменение производительности варьируется от ускорения на более чем 100%, до замедления на 15%. Это самый настоящий прогресс - реализовать ускорение так, чтобы оно тормозило. >что позволило значительно расширить поддержку операций на уровне байткода Тормозной язык по прежнему тормозит, а что насчёт потребления памяти? Почему в каждом анонсе очередного релиза ни слова о том, насколько более прожорливой стала новая версия, из-за накладных расходов JIT компиляции? >Добавлена встроенная игра с текстовым интерфейсом, знакомящая разработчика с новыми возможностями Python 3.15 Мало того, что гвидобейсик заражает проекты не хуже раста, при этом каким-то чудом умудряясь оставаться безнаказанным, так теперь этот мусорный язык стал ещё более мусорным. Эта игра нужна минимуму разработчиков, а у всех остальных несчастных, кто вынуждено использует данный суррогат, это будет лишь зря тратить место. >Реализован вывод рекомендаций при попытке обратиться к несуществующему атрибуту или удалить его. Например, интерпретатор даст знать, если атрибут отсутствует в объекте, но имеется во вложенном объекте или свойстве. При обнаружении несуществующего типа, имеющегося в JavaScript, Java, Ruby или C#, интерпретатор предложит эквивалент для Python. Дожили. Сейчас, когда есть и документация, и IDE и даже нейросети, в гвидобейсик встраивают справочник API из других языков, поскольку им пользуются такие неосиляторы, которые даже переписать код самостоятельно не могут.
Ответить | Правка | Наверх | Cообщить модератору

	73. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (72), 10-Окт-26, 20:37
	>Это же нужно было так суметь создать язык программирования, который не смотря на весь влитый в него капитал умудряется стабильно оставаться на дне, по сравнению с остальными популярными языками. На написании JIT люди дома покупают, не то, что этот ваш SBCL или форт с асмом внутри.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Выпуск языка программирования Python 3.15"	+4 +/–
	Сообщение от Самый анонимный аноним (?), 10-Окт-26, 23:33
	Пожалуй, самый наитупейший комментарий из всех. Даже объяснять лень почему. Автор, уйди и не появляйся здесь никогда.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	124. "Выпуск языка программирования Python 3.15"	–3 +/–
	Сообщение от Аноним (66), 11-Окт-26, 15:22
	Значит флудить не лень, а аргументы приводить лень? Так признавайтесь сразу же, что аргументов у вас нет. И не забудьте гвидобейсик выкинуть.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Выпуск языка программирования Python 3.15"	–1 +/–
	Сообщение от Аноним (171), 12-Окт-26, 10:26
	>видобейсик нужно не ускорять, а выкидывать, и писать на изначально быстрых языках программирования. Питон написан на чистом Си. Куда уж быстрей?
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	182. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 12:27
	Как куда? Как минимум есть SBCL, node и luajit.
	Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск языка программирования Python 3.15"	–1 +/–
Сообщение от Аноним (72), 10-Окт-26, 20:35
>Добавлено ключевое слово "lazy" для отложенной загрузки модулей, при помощи которой можно ускорить запуск приложений с большим числом зависимостей. Оно не для ускорения запуска, а для разрешения циркулярных импортов, которыми каждый типичный питонопроект утыкан - ведь пеп8 рекомендует импортировать qualified, а на операцию ресолва члена модуля тратится поход в хеш-таблицу.
Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Аноним (66), 10-Окт-26, 20:41
>В качестве кодировки по умолчанию задействована UTF-8, независимо от системы в которой выполняется код. Замечательная обратная совместимость и использование мажорных версий.
Ответить | Правка | Наверх | Cообщить модератору

	78. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (78), 10-Окт-26, 22:05
	А когда это в питоне была обратная совместимость?
	Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Джон Титор (ok), 10-Окт-26, 22:27
Куча проектов до сих пор на 3.10 и 3.11. Почему-то этот Питон настолько несовместимый друг с другом что на более новых версиях не запускается или наоборот. А проекты на нем разработчики не хотят переписывать и используют venv, conda. Ещё мне нравится как там устроены менеджеры пакетов. Но это никого не колышит, главное работает.
Ответить | Правка | Наверх | Cообщить модератору

	141. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от User (??), 11-Окт-26, 19:38
	> Куча проектов до сих пор на 3.10 и 3.11. Почему-то этот Питон > настолько несовместимый друг с другом что на более новых версиях не > запускается или наоборот. А проекты на нем разработчики не хотят переписывать > и используют venv, conda. Ещё мне нравится как там устроены менеджеры > пакетов. Но это никого не колышит, главное работает. \Глядя на систему вот на java8\ А кто "совместимый"-то, а?
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Джон Титор (ok), 11-Окт-26, 22:39
	>> Куча проектов до сих пор на 3.10 и 3.11. Почему-то этот Питон >> настолько несовместимый друг с другом что на более новых версиях не >> запускается или наоборот. А проекты на нем разработчики не хотят переписывать >> и используют venv, conda. Ещё мне нравится как там устроены менеджеры >> пакетов. Но это никого не колышит, главное работает. > \Глядя на систему вот на java8\ А кто "совместимый"-то, а? Это то тут причем? Есть что-то весьма современное типа ИИ обертки на java8 и куча либ?
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от User (??), 12-Окт-26, 07:57
	>>> Куча проектов до сих пор на 3.10 и 3.11. Почему-то этот Питон >>> настолько несовместимый друг с другом что на более новых версиях не >>> запускается или наоборот. А проекты на нем разработчики не хотят переписывать >>> и используют venv, conda. Ещё мне нравится как там устроены менеджеры >>> пакетов. Но это никого не колышит, главное работает. >> \Глядя на систему вот на java8\ А кто "совместимый"-то, а? > Это то тут причем? Есть что-то весьма современное типа ИИ обертки на > java8 и куча либ? Да совершенно же ж не при чем. Это же ж только вот python такой унутре себя несовместимый, что проекты на старых версиях интерператора держать можно. А вот то - оно вот ДРУГОЕ, понимать надо!
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Джон Титор (ok), 12-Окт-26, 17:32
	>[оверквотинг удален] >>>> настолько несовместимый друг с другом что на более новых версиях не >>>> запускается или наоборот. А проекты на нем разработчики не хотят переписывать >>>> и используют venv, conda. Ещё мне нравится как там устроены менеджеры >>>> пакетов. Но это никого не колышит, главное работает. >>> \Глядя на систему вот на java8\ А кто "совместимый"-то, а? >> Это то тут причем? Есть что-то весьма современное типа ИИ обертки на >> java8 и куча либ? > Да совершенно же ж не при чем. Это же ж только вот > python такой унутре себя несовместимый, что проекты на старых версиях интерператора > держать можно. А вот то - оно вот ДРУГОЕ, понимать надо! Ой, сделай чай, желательно с мятой, прочитай новость прежде чем что-то писать об этом. А потом пиши слова по смыслу, осмысленно. Про Python.
	Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск языка программирования Python 3.15"	+4 +/–
Сообщение от аниме эксперт (?), 10-Окт-26, 23:00
Сижу на Python 2.7 и не вижу смысла менять, что итак работает.
Ответить | Правка | Наверх | Cообщить модератору

	90. "Выпуск языка программирования Python 3.15"	–1 +/–
	Сообщение от Нонон (?), 11-Окт-26, 01:01
	Надо все равно менять на 3й..
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от аниме эксперт (?), 11-Окт-26, 08:15
	Зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (3), 12-Окт-26, 12:06
	На 3.8.10
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	149. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Инопланетянин (?), 11-Окт-26, 20:49
	Сижу на Python 1.5.2 и не вижу смысла менять, что итак работает.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	154. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Самсоныч (?), 11-Окт-26, 22:14
	Сижу на PHP 5.6 и не вижу смысла менять, что итак работает.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

94. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Аноним (94), 11-Окт-26, 04:40
Питон хорошо для прототипирования, но для серьезной разработки только C++. Зачем сейчас вообще нужны питонисты, если Гугл поиск написал скрипт на питоне по запросу.
Ответить | Правка | Наверх | Cообщить модератору

	104. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Разраб (?), 11-Окт-26, 07:48
	Для прототипирования хорош любой яп которым вы владеете в нужной степени. из личного опыта. ЗЫ про кодировку. Да, ее указывать надо явно как и любые данные, угадайка это не про информатику))
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от но (?), 11-Окт-26, 08:17
	Языком можно владеть как угодно, но если под него нет подходящей либы, то придется велосипедить. А под питон обычно есть
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от _ (??), 13-Окт-26, 17:33
	Что такое "прототипирование" ты не знаешь :) либы нет яЪ :)
	Ответить | Правка | Наверх | Cообщить модератору

109. "Выпуск языка программирования Python 3.15"	–2 +/–
Сообщение от Сергей Макаров (?), 11-Окт-26, 09:30
А нужны ли новые версии? С учётом того что ИИ может безболезненно переписать код на другой язык. Скоро ИИ будет писать сразу в машинном коде.
Ответить | Правка | Наверх | Cообщить модератору

	114. "Выпуск языка программирования Python 3.15"	+2 +/–
	Сообщение от но (?), 11-Окт-26, 10:20
	Всего то кучу денег и в код лучше не заглядывать А еще верить что там никаких CVE
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от iZEN (ok), 11-Окт-26, 10:20
	В общем случае, ИИ теоретически может выполнять роль интерпретатора с естественного языка программиста и JIT-компилятора конструкций абстрактного кода в код целевого процессора. Тут главное ничего не перепутать и правильно объяснить, что хочет программист получить. То есть получается, что принцип "сначала пишем тест" для пока ещё несуществующего кода, здесь встаёт в полный рост.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	146. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от анонимс (?), 11-Окт-26, 20:28
	Тесты пишет LLM и круг нейрослопа пожирающего себя замкнулся😆 Уроборос
	Ответить | Правка | Наверх | Cообщить модератору

118. "Выпуск языка программирования Python 3.15"	+1 +/–
Сообщение от zionist (ok), 11-Окт-26, 11:57
Какой-то слишком маленький прирост в производительности от JIT.
Ответить | Правка | Наверх | Cообщить модератору

	122. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (122), 11-Окт-26, 13:03
	В большинстве случаев ты получишь только просадку. Не путай жит и аот.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от zionist (ok), 12-Окт-26, 12:47
	Я ничего не путаю. JIT придуман именно для увеличения производительности. Например в Java это увеличение существенно больше.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (122), 12-Окт-26, 12:57
	Путаешь, у жавы производительность питона. Житом ускоряются сугубо специфические операции, выполняющиеся постоянно. А производительность увеличивают нативным кодом, потому что жит не может быть бесплатным и универсальным. Размер, разогрев, предсказуемость. Именно поэтому адроид теперь аот вместо жита.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 18:08
	>Путаешь, у жавы производительность питона. Гвидобейсик - один из самых тормознутых языков, среди тех, что используются в индустрии. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Python 3 #6 943.88 https://benchmarksgame-team.pages.debian.net/benchmarksgame/... fannkuch-redux  #8 49.88—55.68 https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Python 3 372.41 https://benchmarksgame-team.pages.debian.net/benchmarksgame/... n-body  #8 7.66 https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Python 3 #2 100.49 https://benchmarksgame-team.pages.debian.net/benchmarksgame/... binary-trees  #7 0.24 Как видно, производительность гвидобейсика крайне позорна. Просто в начале вопиюще безграмонтные программисты гугла зачем-то взяли гвидобейсик, потом не менее безграмотноые менеджеры одобрили вливание в него денег, а дальше его стало жалко выбрасывать, и так вот он и тянется до сих пор, засасывая в себя новых людей.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (122), 12-Окт-26, 18:24
	Ты сейчас серьёзно синтетику за аргумент приводишь? А ну ты используй жаву в режиме интерпретации, вот её реальная производительность.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 20:49
	>Ты сейчас серьёзно синтетику за аргумент приводишь? Зато вы не приводите вообще ничего. Совсем. >А ну ты используй жаву в режиме интерпретации При чём здесь интерпретация? Производительность питона упирается в кучу барьеров, каждый из которых тормозит код. То вместо чисел фиксированной длины будет переменная длина, то вместо таблицы виртуальных функций будет словарь виртуальных функций и так далее. И да, если вам так хочется сравнить скорость чисто интерпретатора, то вот вам пару примеров https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Python умудряется сливать в том числе php, языку, у которого jit-а до недавнего времени не было совсем. >в режиме интерпретации Зачем? Код это не лента, которая идёт строго в одном направлении. Даже условный bash иногда будет включать в себя циклы, на которых будет тормозить.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (122), 12-Окт-26, 21:16
	Ты ещё с перлом сравни. На практике у питона сишная или околосишная производительность и в самом деле значительные куски будут на си, плюсах, фортране, расте, он может задействовать ровно ту же mkl и она быстрее любых альтернатив. Видишь, всё зависит от задач. Синтетика никогда тебе не покажет ничего релевантного. Ты pypy вообще видел? В синтетике унижает, а толку с него.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Аноним (66), 12-Окт-26, 22:24
	>На практике у питона сишная или околосишная производительность и в самом деле значительные куски будут на си, плюсах, фортране, расте Нет, не будет. Всё зависит от того, как много работы нужно сделать на стороне питона. Если взять два сценария: pygame и перекладывание json в БД, то ситуация будет выглядеть всегда одинаково. Если питон делает мало работы, например, условно пять взаимодействующих элементов в игре или пара элементов в json, то замедления от питона будет незаметно, по сравнению с другими языками. Но, как только количество элементов начнёт расти, безразлично, игровые это сущности или элементы json-а, то замедление будет становится всё более и более заметным. Поскольку горячий путь будет одинаковым: взять некий python-объект, привести его в форму для вызова сишной функции, и передать его сишной функции. И чем более сложная логика обработки будет, тем больше будет накладных расходов на сам питон. И если с точки зрения производительности об этом ещё как-то могут подумать, то вот память жалеть точно не будут. >Синтетика никогда тебе не покажет ничего релевантного. Синтетика необычайно релевантна. Если у меня задача, например, написать текстовой редактор, то именно по синтетике и можно понять, во что выльется, если писать, ту же подсветку синтаксиса на целевом языке.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (122), 12-Окт-26, 22:40
	У тебя в реальном коде на питоне даже гила не будет, о чём ты? Ты можешь взять orjson, а можешь simdjson и тут совсем иные результаты будут.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 23:14
	>У тебя в реальном коде на питоне даже гила не будет, о чём ты? Безусловно будет. Любая нагрузка вызовет gil, и не важно что это - обработка десятков тысяч веб страниц в парсере, индексация проекта в среде разработки или веб сервер. >Ты можешь взять orjson, а можешь simdjson и тут совсем иные результаты будут. Зачем? Задача не скопировать json как блоб в БД, а обработать. Если вам нужно будет просуммировать каждый чек в json, или взять и перевести диапазон ip в бесклассовую форму, вы будете на каждую задачу свою библиотеку ставить? >и тут совсем иные результаты будут Если вы делали только простейшие веб формочки на полтора посетителя, то да, вы этих эффектов не заметите.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (122), 12-Окт-26, 23:52
	Какая у тебя нагрузка, если весь код всю работу в конечном счёте делает без питона? И десятки тысяч страниц скачивает и обрабатывает и всё остальное, питон только задаёт параметры и совершает минимальные копирования между нативными батарейками при необходимости. Касательно десятков тысяч страниц, ты, очевидно, не в курсе, но параллельность и многозадачность в питоне реализована на многих уровнях максимально удобно, при этом есть выбор, как задачу лучше реализовать (асинхронные паттерны не всегда хорошо ложаться и только создают паразитную нагрузку). Именно поэтому питон и стал самым популярным языком.
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Выпуск языка программирования Python 3.15"	+1 +/–
	Сообщение от Аноним (66), 13-Окт-26, 12:29
	>если весь код всю работу в конечном счёте делает без питона? Так нельзя говорить даже про bash. Любая логика должна быть реализована. Сколько там строк в django? >питон только задаёт параметры и совершает минимальные копирования между нативными батарейками У вас опять ноль доказательств. Код на питоне далёк от условного cat file | gzip > archive.gz >но параллельность и многозадачность в питоне реализована на многих уровнях максимально удобно, Лгать не надо. Для удобной реализации нужно как минимум избавится от gil. Но, даже после этого, нужна куча других вещей. Но, при чём тут параллельность? Вы в упор игноририруете тот факт, что данные всегда обрабатываются питоном, а не кем-то ещё. Может быть, редкие скрипты с условным numpy и будут исключением, но их всё равно мало. >асинхронные паттерны не всегда хорошо ложаться и только создают паразитную нагрузку Какой бред. Если язык нормальный, а не гвидобейсик, то асихнронные и многоядерные алгоритмы пишутся так же легко, как и синхронные. Берём первый попавшийся софт на питоне https://github.com/Aider-AI/aider/blob/5dc9490bb35f9729ef2c9... - один только файл на 706 строк, всего кода куда больше. Очевидно же, что здесь идёт обработка данных, а не копирование. Берём второй попавшийся софт на питоне https://github.com/sk1-project/sk1-wx/blob/08fcdd0cea179e7d7... - 100% питон, один только файл на 593 строки, суммарно кода куда больше Берём третий попавшийся софт https://gitlab.com/ita1024/waf/-/blob/95b06a7fd602bc96113236... - опять куча файлов, и опять один только файл уже занимает 1401 строку. Три случайных проекта, и первый попавшийся файл уже более чем на полсотню строк, а суммарно в проекте будет их куда больше. >Именно поэтому питон и стал самым популярным языком. Причин популярности питона несколько: крайняя извращённость тех, кто потянул его в гугле и других крупных фирмах, тотальная некомпетентность людей, вплоть до полнейшей неспособности выучить ещё один язык, и полнейшая промытость мозгов, когда люди не чураются любой лжи, лишь бы выставить питон лучше, чем он есть.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 12-Окт-26, 23:04
	>На практике у питона сишная или околосишная производительность Вот для сравнения язык с почти сишной производительностью https://benchmarksgame-team.pages.debian.net/benchmarksgame/... fannkuch-redux C clang #5 8.10 C clang #3 34.14 OCaml #3 8.84 binary-trees C clang #2 1.68 OCaml #2 3.55 C clang 17.86 Разрыв между OCaml и си настолько небольшой, что лучшее решение на OCaml будет быстрее чем худшее решение на си. Возьмём этот случай fannkuch-redux * C clang #4 13.39 OCaml #3 8.84 В описании бенчмарка есть пункт >If the fastest programs are flagged * possible hand-written vector instructions or "unsafe" or naked ffi, does the host language matter? Это значит буквально следующее: обычный код на OCaml оказался быстрее чем вручную оптимизированный код на си. Если учесть тот факт, что написание кода на си - это сбор порчи памяти и прочих проблем, то написание кода на си окупается только готовностью долго оптимизировать и отлаживать каждую строку. Если задача быстро накидать фич, то OCaml безальтернативен, это будет ещё и быстро. А теперь сравним это с кодом на Python https://benchmarksgame-team.pages.debian.net/benchmarksgame/... fannkuch-redux C++ g++ #5 7.86 C++ g++ #3 37.89 Python 3 #4 311.18 Python 3 #8 2,457.09 Разрыв между худшим решением на плюсах и лучшим решением на питоне - более восьми раз в сторону плюсов. Разрыв в лучшем решении на плюсах и худшим решением на питоне - более трёхсот раз. Разница буквально видна невооружённым взглядом. C++ g++ #7 1.01 C++ g++ #2 22.77 Python 3 #4 33.37 Python 3 #2 100.49 Здесь разница между худшим решением на плюсах и лучшим решением на питоне будет чуть меньше, но обогнать хотя-бы один вариант опять не получилось.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	210. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (122), 12-Окт-26, 23:53
	Я вижу, что ты большой поклонник синтетики. Приходи, когда напишешь хотя бы 1 программу (желательно без фреймворков "всё в одном").
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Аноним (66), 13-Окт-26, 12:30
	>Приходи, когда напишешь хотя бы 1 программу (желательно без фреймворков "всё в одном"). Так наличие фреймворков лишь ухудшает итоговую картину. Если питон лишь вызывает пару сишных функций, то он, может быть почти не тормозит. Но вот когда логика целго фреймворка реализована уже на питоне, вот тогда тормоза и будут в полный рост.
	Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Метрика (?), 11-Окт-26, 12:57
Не JIT-компилятор, а интерпретатор с функцией JIT-компиляции, зачем вводить неокрепшие умы в заблуждение, что есть какой там компилятор
Ответить | Правка | Наверх | Cообщить модератору

129. "Выпуск языка программирования Python 3.15"	–1 +/–
Сообщение от Аноним (127), 11-Окт-26, 16:14
Замыкания, продолжения, хвостовую рекурсию и гигиенические макросы уже сделали?
Ответить | Правка | Наверх | Cообщить модератору

	147. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от анонимс (?), 11-Окт-26, 20:29
	На хвостовую рекурсию перевели-переводили сам интерпретатор
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Выпуск языка программирования Python 3.15"	+/–
	Сообщение от Инопланетянин (?), 11-Окт-26, 20:51
	> Замыкания Замыкания там давно есть. Вот многострочных лямбд нет. > хвостовую рекурсию Смысла нет для питона.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

244. "Выпуск языка программирования Python 3.15"	+/–
Сообщение от Аноним (244), 16-Окт-26, 16:24
>для создания уникальных строковых объектов только сейчас что ли? В джаве это уже лет 10 как применяется...
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема