После трёхлетнего затишья в разработке опубликован релиз проекта Pyston 2, развивающего высокопроизводительную реализацию языка Python, использующую наработки проекта LLVM. Реализация примечательна применением современных технологий JIT-компиляции и нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++. Код Pyston написан на языке C++ и распространяется под лицензией Apache...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53987
Но ведь есть же уже numba в виде декоратора? Толку то от этого жита, выше ГИЛа не прыгнешь (в мультипотоке, в однопотоке всё прекрасно).
И первое и второе не работает для "общего случая", не "из каробки" и т.п.С одной стороны, они не воюют с мельницами, оставляя обход многих проблем на плечи пользоватля.
С другой стороны, зачем мне такая "коза с баяном" если (при действительной потребности в скорости) критический питоновский код лучше (!?) и несложно (!?) переписать на С/C++
?
Cython зато для общего случая и из коробки, хоть и не жит, зато сишная производительность 1 в 1. Проставляешь сишные типы для переменных типа счётчиков, отключаешь гил где только с непитоновыми данными работаешь, остальное оставляешь как есть. Удобненько. На самом деле на си переписать сложнее чем ускорить питон в 10000 раз подобным образом. Точно так же с кудой веселее из питона работать.
> Cython зато для общего случая и из коробки, хоть и не жит,
> сишная производительность 1 в 1.What users have to say about Cython:
»SciPy is approximately 50% Python, 25% Fortran, 20% C, 3% Cython and 2% C++ … If Python performance is an issue, then we prefer the use of Cython followed by C, C++ or Fortran (in that order).
Пожалуй, поверю Анониму, а не первому попавшемуся мнению.
Ты вроде и соглашаешься в цитате (заинтересованного лица, надо признать), а потом вроде и соглашаешься в комментарии. Зачем ты это написал?
Сначала я хотел написать, что "сишная производительность" в сравнении с "сишной производительностью" может различаться в 2-3 раза (в зависимости от транслятора и опций сборки), потому заявление насчёт "1 в 1" выглядит несколько наивно. Вот это было бы точно -- незачем.
Я сравнивал ручную cython оптимизацию с аналогичным кодом чисто на си, и cython действительно был быстрее в несколько раз. Но если собрать си с PGO, разница не столь заметна, и в конечном счёте оказалось возможно сделать аналогичную оптимизацию для си (собственно, cython встраивать код на си и позволяет).
Я всегда говорил что Пистон это все что нам нужно для прогресса.
А-тя-тя!
> код Pyston 2 пока недоступенНу и валите с опеннета со своим проприетарным ненужно!
Я очень люблю Python, просто тащусь от этого языка. Но уважаемые, зачем это если есть Go?В смысле этот Пестон Гвидо пилил когда работая в Dropbox чтобы ускорить им там всё. Ну и в итоге они же на Go всё переписали и счастливы.
Ideas? Thoughts? Corrections?
> Я очень люблю PythonА я его ещё больше ку!
Солёное со сладким сравниваете. Go - значимо более низкоуровневый. Прикладные задачи и экосистемы разные. Если бы dropbox изначально писали на go, то может и не было бы этого Dropbox. А когда бизнес устоялся, деньги есть, клиенты есть, ботлнеки известны, серваки деньги кушают, то тогда и оптимизацией можно заняться.
Где сравнение с Nuitka?
А не маловато ли 20%?
Маловато. В моей задаче переписывание с Python на C++ ускорило вычисления примерно в 100 раз. Так что 20% ни о чём.
Они там, похоже, что-то с джитом перемудрили.
Или питон настолько тяжело компилится( тяжелее жс ).С жс-подобным джитом ещё нюансы были, что вначале считается количество вызовов каждой конкретной функции с её последнего изменения и, если оно превышает какое-то значение, только после этого она «компилится». Мб ещё и в этом дело.
>Они там, похоже, что-то с джитом перемудрили.
>близкой к производительности традиционных системных языков, таких как C++вот это и непонятно - хотят ц++, а делают джит
> С жс-подобным джитом ещё нюансы были, что вначале считается количество вызовов каждой
> конкретной функции с её последнего изменения и, если оно превышает какое-то значение, только после этого она «компилится». Мб ещё и в этом дело.Это tracing JIT, который использовался в PyPy (долгое время был академпроектом), еще до появления V8, кхе.
Там правда еще нюансы -- например, "трассируется" не только выполняемый код, но и код интерпретации.> Или питон настолько тяжело компилится( тяжелее жс ).
Просто "подход" к JIT в PyPy был выбран не с бухты-барахты -- народ кучу дипломов и несколько докторских на околопайпаевой теме защитил ;).
Поэтому меня не удивит, если это "почти оптимальный" JIT для динам. типизированных ЯП этого класса и "уровня" возможностей/разработки[0]
Соответственно, если делать "главное, чтоб не как у этих!" (утрирую конечно) -- легко нарваться на тормоза.[0] т.е. при отсутствии финансирования большой и высококвалифицированной комманды разработчиков Goolge/Mozilla.
Дооо. То то питонщики последний хрен с солью доедают, но это к слову о финансировании и поддержке, а так же о том, что питон нынче ставится во многие дистрибутивы линухи в отличие от ноды.Парадокс их «академической оптимальности» в том, что получился тормозной мусор в сравнении с тем же жс. Хотя исходники и хромиума и вебкита открыты и, если своих мозгов настолько не хватает, то можно и дергануть кусок-другой кода.
.. но даже JIT питону даёт лишь 20% ускорения..Мб это реально далеко не лучший язык даже для скриптовой разработки, если уж отзывчивость даже на столь серьёзные изменения у него околонулевая ?
>далеко не лучший языкПо производительности - худший.
> Дооо. То то питонщики последний хрен с солью доедают, но это к слову о финансировании и поддержке, а так же о том, что питон нынче ставится во многие дистрибутивы линухи в отличие от ноды.Э-э-э, и? Причем тут абстрактные "питонщики", если речь о вполне конкретных проектах (типа сабжа)? Ни у одного из них и близко не было такого финансироавния, как у движка JS в гугле/мозилле/ябле.
PyPy развивался (до 2015, далее я не следил особо) в основном студентами, под "руководством" кандидатов.
К слову, браузер с V8 сейчас вообще ставится и на десткопные линуксы и винды в 85% (или сколько там сейчас у хрома процентов?) случаев. "И че?" (c)
> Парадокс их «академической оптимальности» в том, что получился тормозной мусор в сравнении с тем же жс.Угу-угу. Правда, факт в том, что сделать JIT лучше пока ни у кого не получалось, как бы не пыжились. И самый эффективный JIT для JS -- тоже (вот так совпадение) tracing JIT.
Ну и что V8/spidermonkey играют в "другрой финансовой лиге", тоже "типа факт", поэтому сравнения и "выводы" хромают на обе ноги.
Хотя лет 5 назад PyPy c V8 вполне еще были "наравне". Что сейчас, я не в курсе, но раз уж вас так тянет поговоирть мимо темы, о JS (видимо о наболевшем) то наверняка не затруднит дать ссылочку на пару нормальных бенчмарков, нет?> Хотя исходники и хромиума и вебкита открыты и, если своих мозгов настолько не хватает, то можно и дергануть кусок-другой кода.
Раз уж вас не смущает "несущественная" разница в типизации, наследовании и прочем (историческая куча сишных либ и обвязок, совместимость с которыми хочется сохранить), как и цель сабжа в виде "экономии памяти" (нода жрет раз в 5-10 больше) -- дергайте, так и быть, разрешаю.
> .. но даже JIT питону даёт лишь 20% ускорения..
Это вообще к чему? Pypy "дает" в разы больше, а сабж ... ну, JIT подходы, они ведь разные бывают: "техника вероятностного предсказания типов объектов с последующим уточнением правильности выбора типа в процессе выполнения".
"ну не шмогла, я, не шмогла" (с)> Мб это реально далеко не лучший язык даже для скриптовой разработки, если уж отзывчивость даже на столь серьёзные изменения у него околонулевая?
Угу-угу. Сравнить очередную разработку "авось что выйдет" 3½ человек с гугло-мозиллой "throw hardw^W money at it! More! More!" и сделать какие-то "интересные" выводы.
Только вот о проектах схожего уровня для JS вообще что-то ни слуху ни духу, видимо "лучшесть" сказывается 🙄
> Э-э-э, и? Причем тут абстрактные "питонщики", если речь о вполне конкретных проектах
> (типа сабжа)? Ни у одного из них и близко не было
> такого финансироавния, как у движка JS в гугле/мозилле/ябле.
> PyPy развивался (до 2015, далее я не следил особо) в основном студентами,
> под "руководством" кандидатов.
> К слову, браузер с V8 сейчас вообще ставится и на десткопные линуксы
> и винды в 85% (или сколько там сейчас у хрома процентов?)
> случаев. "И че?" (c)Финансирование подразумевает разработку чего-то нового. Продукты, в которые вложено немало денег, имеют открытый исходный код. С чего бы на фоне этого питонщикам требуется финансирование, соразмерное разработке полностью с нуля без наличия каких-либо аналогов ?
Уже даже в пых( который едва ли имеет какое-то невероятное финансирование ) jit подвезли, притом, давно.. но он и без него был быстрее питона.> Угу-угу. Правда, факт в том, что сделать JIT лучше пока ни у
> кого не получалось, как бы не пыжились. И самый эффективный JIT
> для JS -- тоже (вот так совпадение) tracing JIT.
> Ну и что V8/spidermonkey играют в "другрой финансовой лиге", тоже "типа факт",
> поэтому сравнения и "выводы" хромают на обе ноги.
> Хотя лет 5 назад PyPy c V8 вполне еще были "наравне". Что
> сейчас, я не в курсе, но раз уж вас так тянет
> поговоирть мимо темы, о JS (видимо о наболевшем) то наверняка не
> затруднит дать ссылочку на пару нормальных бенчмарков, нет?Это все не более чем отговорки.
В случае с PyPy и V8 - их вообще корректно сравнивать ?Яндекс/Гугл в помощь.
Я не собираюсь тратить ни секунды времени на поиски только потому, что вам самим жалко тратить на это время.> Раз уж вас не смущает "несущественная" разница в типизации, наследовании и прочем
> (историческая куча сишных либ и обвязок, совместимость с которыми хочется сохранить),
> как и цель сабжа в виде "экономии памяти" (нода жрет раз
> в 5-10 больше) -- дергайте, так и быть, разрешаю.Питон и "историческое сохранение совместимости" - это вообще совершенно разные вещи и JIT тут не при чем )
Где-то в 5-10, где-то - не в 5-10.
> Это вообще к чему? Pypy "дает" в разы больше, а сабж ...
> ну, JIT подходы, они ведь разные бывают: "техника вероятностного предсказания типов
> объектов с последующим уточнением правильности выбора типа в процессе выполнения".
> "ну не шмогла, я, не шмогла" (с)О том и речь, что "не шмогла" ( хотя иные очень даже смогли ).
> Угу-угу. Сравнить очередную разработку "авось что выйдет" 3½ человек с гугло-мозиллой
> "throw hardw^W money at it! More! More!" и сделать какие-то "интересные"
> выводы.
> Только вот о проектах схожего уровня для JS вообще что-то ни слуху
> ни духу, видимо "лучшесть" сказываетсяКакого уровня ? -Жс уже давно прошел через минус_первый и нулевой левел.
> Мб это реально далеко не лучший язык даже для скриптовой разработки, если
> уж отзывчивость даже на столь серьёзные изменения у него околонулевая ?Для скриптовой он очень неплох, хотя и перемудрён уже (особенно неочевидна семантика изменяемых объектов). Запускается интерпретатор Питона быстро, с такой же скоростью, что и ocaml Toplevel, в несколько раз медленее bash, но это терпимо.
> Маловато. В моей задаче переписывание с Python на C++ ускорило вычисления примерно
> в 100 раз. Так что 20% ни о чём.Ну обычно просто вдумчивое переписывание с Питона на Питон серьёзно ускоряет программу.
> Ценой использования JIT является незначительное увеличение потребления памяти.И значительное снижение безопасности.
JIT требует отключение защиты памяти процессором и ядром OS, делая вашу систему уязвимой к переполнению буфера.
Это с какого перепуга?
JIT -> изменение исполняемой памяти -> возможность эксплуатации уязвимости переполнения буфера.Нет JIT -> запрет на любое изменение исполняемой памяти -> невозможность эксплуатации переполнения буфера.
Я всегда работал с обычными компилируемыми языками, поэтому JITом никогда не интересовался, но разве там не просто "скомпилировали в нативный бинарик, бросили в кеш чтобы не компилировать в следующий раз и запустили самый обычный нативный блоб"?
Нет. То что ты говоришь - AOT
> JIT -> изменение исполняемой памятиЧушь собачья! JIT совершенно не подразумевает, что что-то должно изменяться. Почитай-ка лучше теорию, а потом садись за математику - завтра в школу.
JIT - исполнение скомпилированного во время работы программы кода, который надо записать в память (доступ на запись, W), а потом исполнить (исполнение, X, измененного во время работы программы кода).
> JIT -> изменение исполняемой памяти -> возможность эксплуатации уязвимости переполнения буфера.простой интерпретатор без JIT -> исполнение высокоуровневого кода в неисполняемой памяти -> эксплуатация уязвимости в обход ASLR.
> Нет JIT -> запрет на любое изменение исполняемой памяти -> невозможность эксплуатации переполнения буфера.
Только в моей реальности, в скриптовых/ЯП c автоматическим управлением памятью, уязвимости переполнения буфера встречаются куда как реже, чем уязвимости с каким нибудь хитрым eval(userinput).
В твоем дистре ядро разрешает исполнение левых скриптов?Не спрашиваю уже о ограничениях интерпретаторов средствами DAC.
>Нет JIT -> запрет на любое изменение исполняемой памяти -> невозможность эксплуатации переполнения буфера.Не полная невозможность, а только увеличение сложности эксплуатации. Если правильно подобрать данные, то переполнение буфера прыгнет на инструкцию в системном коде, которая вызовет функцию изменяющую атрибуты памяти в которой расположен shell-код, а затем "вернёт" управление ему. Именно поэтому и существует рендомизация адресного пространства, которая значительно усложняет ориентацию в коде процесса.
Согласен, что ALSR также необходимо использовать в ядре OS и программах.Но в этой теме акцент на вредность JIT для защиты памяти OS. Если JIT нет то в OS можно реализовать простую защиту от переполнения буфера. А если JIT есть то защиту просто не реализуешь, будет дыра в OS и угроза переполнения буфера.
Простая защита это именно флаг запрещающий выполнять определённые области памяти, чтобы сделать защиту получше, нужно сломать ядерный ABI, который позволяет снимать запрет. Но в таком случае вполне возможно выполнять JIT-код в контейнере, который не может самостоятельно менять права страниц своего процесса и вообще может только общаться с процессом-мастером.
> который позволяет снимать запрет.Все зависит от реализации защиты: строгая или не строгая.
Нормальные ядра OS запрет снимать не разрешают и никакой JIT исполнить тоже не разрешат.
> Нормальные ядра OS запрет снимать не разрешают и никакой JIT исполнить тоже
> не разрешат.POSIX:mprotect Ни одна нормальная ОС не может реализовать POSIX!
> Ни одна нормальная ОС не может реализовать POSIX!И нормальная и посикс держит: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
> то переполнение буфера прыгнет на инструкцию в системном коде, которая вызовет функцию изменяющую атрибуты памятиНу прочитаешь, ну прыгнешь, а исполняется память только для чтения. Ядро ловит попытку записи в область помеченную только для чтения и убивает вирусный процес.
>Ну прочитаешь, ну прыгнешь, а исполняется память только для чтения.
>Ядро ловит попытку записи в область помеченную только для чтения и убивает вирусный процес.Инструкция в системном коде имеет разрешение на выполнение, иногда даже компилятор не в курсе, что сгенерировал инструкцию, которая может прыгнуть в mprotect. Это просто байты так уж сложились. После mprotect вирусный код получает своё "законное" право на выполнение.
Ты не имеешь права записи в области которые доступны только для чтения. Все исполняемые области, в нормальных ядрах OS, доступны только для чтения.Плевал я на программиста и его компилятор, контроль за памятью есть у ядра OS и процессора и при попытке записи в область доступны только для чтения ядро нормальной OS убьет процес.
Да не работает это всё, в том и дело. Только полный запрет mprotect может решить проблему, но это сломает ABI.
У меня на компе все работает, за малым исключением: firefox, kwin-wayland, polkitd, orc - эти программы выкинул; все остальное пересобрал без JIT с оптимизацией под свой процессор.Не пользуйтесь дистрибутивами GNU/Linux и BSD* где нет строгой защиты памяти W^X.
> то переполнение буфера прыгнет на инструкцию в системном коде, которая вызовет функцию изменяющую атрибуты памятиНу просчитаешь, ну прыгнешь, а вся исполняемая память доступна только для чтения. Ядро ловит попытку записи в область помеченную только для чтения и убивает вирусный процес.
"Что это проприетарное ненужно делает на опеннете?!"
Лютобешено плюсую.Где новости про хруст ?
Может легче на C# писать? И синтаксис лучше и jit есть
jit у C#? Это о чём вообще?
ты сам понимаешь о чем спрашиваешь?
в C# есть tiered JIT и довольно хороший
Там всё вот в таком порядке: c# компилируется IL (такой типо ассемблер для VM дотнета), а затем IL уже обрабатывается джитом в момент исполнения. То есть, JIT - это фича CLR, а не C#.Поэтому комментатор выше вас в чем-то прав, хоть скорее всего сам об этом не догадывается
Пестон можно хоть на гиперкварках запилить, СМЫСЛ? Неужели вы думаете, мы не трогаем это ***овно только из-за скорости?? САМ ЯЗЫК - ушлёпский и "синтаксис на отступах" - самая несусветная чушь, которая могла прийти в голову. Так что пилите, Шура, пилите! Мы всё равно не будем касаться этого неадеквата.
> "синтаксис на отступах" - самая несусветная чушь, которая могла прийти в голову.Кому очень не хватает скобок, могут писать так:
## {
def method():
pass
## }редакторы скобки обычно подсвечивают везде.
Спасибо, мы лучше на нормальных языках писать будем.
> Кому очень не хватает скобок, могут писать так:Не все фанаты юмора монтипайтона, и любая шутка со временем становится невыносимо отталкивающей.
>flaskblogging memory usage 47MB 54MB 228MBНужно!
Чуть было не прочитал "Python 2", аж флешбеки свело.
>PystonА-тя-тя-тя-тя.
Они пытаются сделать второй PyPy?
Нэт.
Pyston: "We’re on a mission to make Python faster".
PyPy: "A fast, compliant alternative implementation of Python".У первого, получается, (пока что) хуже с fast, но лучше с compliant, как я понял.
> Pyston: "We’re on a mission to make Python faster".Ну тогда у тебя Cython - это тоже что Python. Как-то так.
>> Pyston: "We’re on a mission to make Python faster".
> Ну тогда у тебя Cython - это тоже что Python. Как-то
> так.Cython, как я понимаю, еще менее совместим с эталонной реализацией.
Оба не реализуют весь язык Python. Понятное дело, что программисты не используют всех возможностей и что-то работать будет.
Но Гвидо назвал питоном то, что назвал. Надо либо всё реализовать, либо не говорить, что это реализация питона. Зачем выдавать желаемое за действительное?
А зачем? Причесали бы Cython, дали бы возможность использовать его без зависимости от libpython, упростили бы возможность использования его целиком для написания программ на нём, а не только модули для питона писать, сделали бы возможным разрабатывать на нём кроссплатформенные приложения, чтобы и под Андроид было легко на нём писать и он взлетел бы, даже без совместимости с обычным питоном, с которого все с радостью ушли бы на это. Питон любят только из-за синтаксиса.
Расскажите мне, почему питон такой модный? Вроде он и не очень быстрый и не очень типизированный, и многопоточка у него не фонтан, и в сборке мусора ничего особенного, и синтаксис далеко не всем нравитсяОт чего все кипятком ссyтся?
фишка в том, что питон относительно простой. реально простой. ничего не знающий человек уже через неделю сможет выдавить далеко не только хелловорды. и синтаксис у него многим нравится. не нравится тем , кто уже многие годы пишет на компилируемых в основном языках( отсюда и пошло сражение скобок и отступов). ну непривычно им. мне например нравится стройность написания на питоне. открыл как то код на плюсах и не сразу понял что там хотели и как реализовали, иногда код си/с++ довольно тяжело читать. да и скажем прямо такие инструменты низкоуровневые требуют долгого времени обучения и понимания. питон намного проще, но дает заметно более низкое понимание работы самого компьютера, но быстро написанный код даже маломальски подготовленного человека. вот и его популярность. можно быстро подготовить армию кодеров на питоне. на плюсах такого не выйдет.
Питон проще других языков только по одной причине. Во всех гайдах по нему описывается ОДИН И ТОЛЬКО ОДИН правильный способ делать что-то. В других языках программисту нужно больше думать.
даже этот один правильный способ ведет к сотням и тысячам вариаций одного и того же. и это неплохо. те же плюсы это жесть , которую учить надо всю жизнь и фиг выучишь, он очень разжирел. но как инструмент он намного превосходит питон, да и раст скорее всего тоже. но его жуткая усложненность всех вводит в гневный ступор.)) в плюсах знать надо неимоверно много.
В прошлый раз, когда я хотел использовать плюсы, мне пришлось вымазаться в бусте с ног до головы. Я всё ещё надеюсь, что они посмотрят на раст и его эксперименты, и утянут себе в срандарт всё стоящее утягивания, и тогда все любые языки помимо плюсов отомрут. Особенно я надеюсь отомрут дотнет с жавой. А из скриптов пусть останется питон, идеальный вариант.
> отомрут дотнет с жавойНе отомрут пока есть windows, android и горы промышленного софта.
В тоже время котлин вполне себе приятный, а c# развивается очень быстро.
Скорее вас таких программистов заменят нейросетью на проце, потребляющим 10 Вт, чем отомрет джава.
Программирование на любом языке примерно одинаково. И все они очень похожи, если не считать экзотику и 1С. Знать для эффективного программирования надо очень много. Где-то два высших образования по объему. Быстро это не заходит.
Собственно поэтому от легкости освоения языка программирования мало что меняется. Ну выучил ты синтаксис языка, и что дальше. Программировать все еще предстоит научиться. Структуры данных, алгоритмы, проектирование, куча сопутствующих технологий. В дальнейшем на передний план выходит организация процесса разработки, тестирования, сопровождения кодовой базы.
К старости можно стать более или менее компетентным во всем.
Вне среды восторженных школьников и младших научных сотрудников он не очень-то используется.
Моду на питон ввела компания гугл, внутри которой это до сих пор основной язык, на котором все работает.
В гугле "всё работает" на с++
>В гугле "всё работает" на с++Парсить текст, отличный от латиницы, на C или C++ то еще удовольствие. Там поддержки UTF-8 из коробки нет, и не предвидится.
Сделать хоть какую-то корректную либу для работы с UTF-8 дело примерно недели или двух, если не нужно заморачиваться с юникодом, то можно уложиться в несколько дней. Несложно догадаться что подобные либы для плюсов давно написаны многими и для разработки внутри организации типа G идут для разработчика в коробке с кучей других либ.
Только критичные к производительности вещи.
На плюсах пишут весь код, который должен быстро работать или оптимально использовать другие ресурсы (память, например) или корректно работать с ~POSIX API или алгоритмически сложен или если в компоненте ппросто много кода. Второй такой ЯП с чуть худшими характеристиками это Java. На C++ и Java реализуется подавляющая часть технически сложных решений ради которых G высасывает(ал) инженеров со всего мира.Ниша питона везде, и в G в частности, скриптовщина для автоматизации инфраструктуры и прослойка между нормальнымы сервисами и веб помоями. Где-то между первой кучей и питоном влезает Go. Ну и разумеется G не имеет отношения к моде на питон.
Так уж вышло, что я из первых рук знаю, что в гугле питон используется отнюдь не только для автоматизации, но и для обработки основных пайплайнов. Го в гугле используется очень мало.И к моде на питон отношение самое прямое. Один из основных аргументов в форсировании этого языка всегда было, что вот он в гугле используется.
Потому что альтернативы ещё хуже
Может еще потому, что есть механизмы устранения косяков языка? PEPs, вот это вот все.До питона такое было в scheme (в какой-то степени) - но, видимо, скобочки очень сильно пугают.
Python не проще в освоении, как об этом ниже говорят. По сложности он скоро C++ догонит, если уже не догнал. Его особенность в том, что на нем писать проще, когда уже его освоил. Например, не надо следить за числовыми типами - то есть следить за тем, когда int превратится во float, или обратно, или за переполнением этого типа и заменой его на более вместительный. Эти интерпретатор занимается. Легкая работа со строками (парсинг строк нужен постоянно). Куча батареек.
И наконец, Python интерпретируемый язык. А у интерпретируемых языков преимущество в том, что написал код и сразу его выполнил. В отличии от компилируемых, где соответственно нужна компиляция, да еще и мейкфайл потребуется (что само по себе лишняя работа), если исходного файла у программы больше одного. А среди интерпретируемых конкурент у Python -а только Perl. Но исходный код, написанный на языке Perl, как говорили некогда в одном журнале, не всегда понимают даже сами авторы. :D
Perl типа компилируется перед запуском. В том числе поэтому он в разы быстрее.
Насчет понятности - большой вопрос. Лапшу на питоне понимать не проще, чем лапшу на перле.
На перле можно очень чисто писать и код будет понятнее, чем на питоне с его отступами и общей кондовостью. Хороший код на питоне написать сложнее, чем хороший код на перле.
>Perl типа компилируется перед запуском. В том числе поэтому он в разы быстрее.Я понимаю, что вам нравится Perl, а не Python. Но сказки все-же выдумывать не нужно. Быстрее Perl лишь иногда, и уж точно не в разы (в пределах 20%, насколько я знаю). И вполне возможно написать модуль для Python на C (а их много на C написано). И использовать его. И быстрота Perl -а, о которой вы говорите, останется не при делах.
Если сравнивать производительность самого языка, то в пределах 20%. А если производительность программ, на них написанных, будет уже в разы. С сишными модулями или без (в перле тоже много сишных модулей).
Поверьте на слово - любую прогу на питоне можно переписать на перле и она станет короче в два раза и будет работать намного быстрее.Как выше писали, многие вещи в питоне просто не работают нормально. А в перле работают. Можно упрямо этого не признавать и продолжать плакать и колоться, а можно сменить инструмент.
Нет, не на перл. Питонистам следовало бы присмотреться к luajit.
>А если производительность программ, на них написанных, будет уже в разы. С сишными модулями или без (в перле тоже много сишных модулей).Если и там и там сишные модули, и если допустить, что написаны они грамотно, то работать программы будут примерно одинаково. Разам неоткуда браться. В равных условиях будут те же максимальные 20%, да и то не факт.
>Поверьте на слово - любую прогу на питоне можно переписать на перле и она станет короче в два раза и будет работать намного быстрее.
Сильно короче программа может стать только в том случае, если в ней используются модули, которых в Python нет. Сам же код может быть можно написать короче только за счет языковых конструкций, которых в Python нет. Не думаю, что в Perl -е много таких конструкций.
>Как выше писали, многие вещи в питоне просто не работают нормально.
Если код написан криво, то он и там, и там нормально работать не будет. Причем тут Python?
Я не первый год пользуюсь Python и тоже уверено могу сказать, что работает он вполне неплохо. Если конечно не пытаться им заменять компилируемые языки.
Вы просто не знаете перл и думаете, что это как питон, только перл :)
Перл - особенный язык. После перла все остальное кондово и уныло, кроме луа, жс и может быть си.>Сильно короче программа может стать только в том случае, если в ней используются модули
Я имел в виду именно код на языке. Простые скрипты на питоне размером где-то в экран можно иногда в однострочник на перле превратить. Так уж питонисты пишут.
>Простые скрипты на питоне размером где-то в экран можно иногда в однострочник на перле превратить. Так уж питонисты пишут.Дзен Python гласит: "простое лучше, чем сложное" и "читаемость имеет значение". Питонисты правильно пишут. Натягивать весь доступный код на одну строку - идея сомнительная. Читаются такие строки обычно плохо.
Могу только посоветовать освоить перл и самому все понять.
На кой хрен он мне сдался?! Мне вполне хватает Python -а, Go, и C, чтобы не впадать в иллюзии, и не изучать язык, который заведомо мне особо ничего не даст.
Хватает - а ты попробуй выйти за пределы своей зоны комфорта.
>Хватает - а ты попробуй выйти за пределы своей зоны комфорта.Зачем? Чтобы кактус погрызть?
Перл для тебя будет слишком сложен. Попробуй освоить для начала луа.
Хватит уже бредятину нести. Я тебе не просто так цитировал дзен Python. О программировании у тебя представление довольно слабое. Вместо того, чтобы прочитать и сделать правильные выводы ты начал меня поучать.
Ты о Python -е имеешь еще меньшее представление, чем я о Perl. Только я на знание Perl и не претендовал. Python больше, чем Perl, умник, и соответственно сложнее в освоении. А Lua вообще не конкурент ни тому, ни другому, это небольшой встраиваемый язык.
Просто пёрл не для вас. Вы для него... не подходите.Я полностью понимаю вашего собеседника, он познал сладость пёрла на кончиках пальцев и ходит руки в боки.
Вы только не горячитесь, не всем дано понимать пёрл, это нормально.
блин, не туда ответил
>О программировании у тебя представление довольно слабоеОк )))
>это небольшой встраиваемый язык
Когда-то про JS писали, что это встроенный в браузер язык. А потом появилась нода и даже электрон.
> Python больше, чем Perl
Только по количеству так называемого "дзена".
>Когда-то про JS писали, что это встроенный в браузер язык. А потом появилась нода и даже электрон.Ты не понял. Область применения у Lua такая. То есть он и предназначен для того, чтобы в различные программы его встраивать. Например, оконный менеджер Awesome его в этом качестве использует. Или в играх он используется, в S.T.A.L.K.E.R -е, например. А именно отдельно его используют не так, чтобы часто. Вот так, навскидку, я могу припомнить разве что расширения для Conky, которые писали на Lua.
>Только по количеству так называемого "дзена".
Дзен Python - это 19 строк текста. Это всего лишь рекомендации разработчиков о том, как правильно следует писать код. Я имел в виду, что сам язык немаленький. Говоря метафорически питон - это "киллометровой" длины змея. :D
Так 3 экрана кода на перл тоже можно превратить в однострочник на питоне, так уж перлисты пишут. Особенно теперь, когда ввели := (но в f-строках нельзя использовать, печаль).>уныло, кроме луа
ох щи ;))
Перловики-макаки давно вымерли как динозавры 10 лет назад.
Перловик в 2020 это почти всегда сильный программист, знающий кроме перла еще 2-3 языка. В отличие от питонистов, которые проходят курзеру и пишут черт знает что.
Ты так говоришь, будто на питоне всерьёз пишут не профессионалы с пятью языками в бэкграунде. Перл, конечно, имеет довольно приятный синтаксис как для скриптов (пока не захочешь обмазаться ООП, емнип), но у него сегодня нет никаких преимуществ и одни недостатки. Профессионал выберет более современный и актуальный инструмент, несмотря на персональный фетиш к закорючкам. Хотя и тут жс заменяет перл, питон просто меньше про синтаксис и закорючки и больше про логику, "дрюжелюбность к пользователю", и меньше возможностей наплодить багов и всё это при отличном интеропе с чем угодно.
С регулярками в питоне постоянно приходится сражаться конечно, перловые повеселее. Если мне нужны только регулярки, я выберу перл не думая два раза. Но, с другой стороны, там нет ничего настолько необходимого, чтобы выбрать перл из-за них. Опять же, всё зависит от задачи, может, там баша с седом за глаза (как это часто бывает).
> Вы просто не знаете перл и думаете, что это как питон, только
> перл :)Люблю пёрл. И регулярки. Простите мне мою слабость
> не надо следить за числовыми типами - то есть следить за
> тем, когда int превратится во float, или обратно, или за переполнением
> этого типа и заменой его на более вместительный.Вот тут не понял. Судя по вашим словам в питоне много неявных числовых приведений, которые, наоборот, нужно всегда учитывать. По мне так это избавляет от одних проблем и пораждает другие
Никаких проблем это не порождает. Типизация строгая. Надо просто понимать, как это работает. А если уж совсем хочется, то есть анотация типов. То есть, чтобы исключить какую-то путаницу в понимании, можно указать типы.
Потому что препоадается в школах и колледжах не один год, в дополнение к массовому применению в науке-- не очень быстрый
если у приложения главный затык - ожидание ответа сторонненого сервиса - то пофик-- и не очень типизированный,
у динамической типизации есть и достоинства. чем меньше кода, тем ее применение более оправдано чем статической.а если нужна статическая - то и у Python и у PHP, и у JavaScript есть для этого средства.
Зато у программистов выбор - хочешь/надо - используй, не хочешь, не надо - не используй.
-- и многопоточка у него не фонтан
однопоточный код писать нааамного проще и быстрее.
а уж сопровождать многопоточный код...и он нужен он не часто.
а там где нужен на проектах с Python, PHP - его выносят на сервисы на Go, да и все.
На Ноде достаточно ее асинхронщины и подъема нескольких инстансов приложения
-- в сборке мусора ничего особенного
а что должно быть такого особенного в сборке мусора :)
Собирает? задержки приемлимы для проекта - значит ОК.Не приемлимы задержки? берите другое, как недавно дискордовцы переписали один из своих сервисов с Go на Rust
-- синтаксис далеко не всем нравится
да, помню холивары о синтаксисе С и Pascal
когда студентом был :)к синтаксису привыкаешь быстро.
хоть к питоновскому, хоть к лисповскому.
если не студент - это не проблема.Религии только не надо делать с инструмента.
Тогда понятно станет что полезного в каждом инструменте, а какова стоимость этой полезности.
> однопоточный код писать нааамного проще и быстрее. а уж сопровождать многопоточный код...Спасибо, капитан!
Наконец-таки кто-то ещё догадался, что LLVM в качестве JIT подходит только таким математическим применениям, как Julia.
это для python 2 ?
если нет - то ненужно