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

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

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

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

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

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

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

9. Сообщение от Аноним (9), 10-Окт-26, 14:35	+/–
А потом Doom?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #13, #40

10. Сообщение от inferrna (ok), 10-Окт-26, 14:41	–4 +/–
Версию 3.16 перепишут с нуля на расте. Запомните этот твит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #25, #27, #37, #61, #92, #137, #174

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

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

13. Сообщение от BrainFucker (ok), 10-Окт-26, 14:43	+1 +/–
Было такое выражение doom scrolling, а это будет doom coding.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

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

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

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

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

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

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

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

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

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

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

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

31. Сообщение от Аноним (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ообщить модератору
Родитель: #22 Ответы: #131, #177

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

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

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

38. Сообщение от Аноним (38), 10-Окт-26, 18:15	+/–
Ага, особенно в Си и С++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

65. Сообщение от Аноним (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, #88, #171

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

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

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

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

70. Сообщение от limafresh (ok), 10-Окт-26, 20:26	+3 +/–
Для тех, кто будет кодить руками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #76

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

90. Сообщение от Нонон (?), 11-Окт-26, 01:01	–1 +/–
Надо все равно менять на 3й..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #105, #178

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

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

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

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

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

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

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

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

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

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

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

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

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

105. Сообщение от аниме эксперт (?), 11-Окт-26, 08:15	+/–
Зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

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

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

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

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

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

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

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

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

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

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

116. Сообщение от 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #123, #181

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

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

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

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

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

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

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

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

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

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

130. Сообщение от 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ообщить модератору
Родитель: #123 Ответы: #132

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

132. Сообщение от Ivan_83 (ok), 11-Окт-26, 16:37	+1 +/–
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ообщить модератору
Родитель: #130

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

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

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

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

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

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

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

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

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

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

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

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

145. Сообщение от BrainFucker (ok), 11-Окт-26, 20:28	+/–
А эти инфраструктуры сейчас с вами в одной комнате?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #220

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

147. Сообщение от анонимс (?), 11-Окт-26, 20:29	+/–
На хвостовую рекурсию перевели-переводили сам интерпретатор
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ообщить модератору
Родитель: #153 Ответы: #169

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

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

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

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

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

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

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

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

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

178. Сообщение от Аноним (3), 12-Окт-26, 12:06	+/–
На 3.8.10
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

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

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

182. Сообщение от Аноним (66), 12-Окт-26, 12:27	+/–
Как куда? Как минимум есть SBCL, node и luajit.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

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

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

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

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

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

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

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

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

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

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

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

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

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

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

197. Сообщение от Аноним (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ообщить модератору
Родитель: #186 Ответы: #199

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

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

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

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

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

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

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

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

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

207. Сообщение от Аноним (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 Здесь разница между худшим решением на плюсах и лучшим решением на питоне будет чуть меньше, но обогнать хотя-бы один вариант опять не получилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #210

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

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

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

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

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

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

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

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

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

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

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

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

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

222. Сообщение от Аноним (66), 13-Окт-26, 12:29	+1 +/–
>если весь код всю работу в конечном счёте делает без питона? Так нельзя говорить даже про 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ообщить модератору
Родитель: #209

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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