Компания Google открыла (https://opensource.googleblog.com/2017/01/grumpy-go-running-...) исходные тексты проекта Grumpy (https://github.com/google/grumpy), в рамках которого развивается экспериментальный Python runtime для языка Go. Grumpy обеспечивает трансляцию кода на языке Python в представление на языке Go и позволяет бесшовно запускать оттранслированные Python-программы в runtime-окружении языка Go. Отмечается, что одной из основных целей проекта является обеспечение высокого уровня совместимости с CPython и достижение возможности применения Grumpy в качестве полноценной замены Python runtime для проектов на языке Python. Код транслятора написан на языке Python и поставляется (https://github.com/google/grumpy) под лицензией Apache 2.0.
Grumpy нацелен на использование в качестве прозрачной замены CPython 2.7 и позволяет решить проблемы с плохой работой CPython в условиях обработки массовых параллельных запросов. В частности, одной из поставленных перед Grumpy задач была оптимизация работы API YouTube, написанного на Python и обрабатывающего миллионы запросов в секунду. Grumpy не формирует байткод и не использует виртуальную машину. На выходе генерируется набор обычных исходных текстов на языке Go, которые затем могут быть преобразованы в машинный код при помощи штатного компилятора Go. В полученных после компиляции исходных текстах продолжают использоваться специфичные для Python структуры данных.
Реализация структур и API оптимизированы для хорошей масштабируемости в условиях массовой параллельной обработки данных. Grumpy избавлен от ключевой проблемы Python - глобальной блокировки интерпретатора (GIL, Global Interpreter Lock), не допускающей параллельного выполнения нескольких нитей кода. Grumpy также использует сборщик мусора Go для управления жизнью объектов вместо применяемой в Python системы на основе подсчёта ссылок. В сочетании с компиляцией в исполняемый код, подобные улучшения позволяют добиться существенного прироста производительности. Уровень масштабируемости Grumpy хорошо демонстрирует нижеприведённый график, отражающий результаты прохождения теста производительности Fibonacci:
Grumpy состоит из трёх основных компонентов:
- grumpc - компилятор, выполняющий разбор кода на языке Python и генерацию кода на языке Go. Для разбора используется модуль ast (https://docs.python.org/2/library/ast.html) (Abstract Syntax Trees);- Grumpy Runtime. Сформированный код на языке Go оперирует структурами данных, представляющими Python-объекты. Данные структуры и операции с ними определены в runtime-библиотеке grumpy, реализованной по аналогии с Python C API;
- Стандартная библиотека Grumpy. Большинство штатных библиотек Python написаны на языке Python и без проблем работают в Grumpy. Стандартная библиотека Grumpy является незначительно модифицированной копией stdlib из состава CPython 2.7. Python-библиотеки в которых используются модули на языке Си переписаны на Python, но используют родные расширения языка Go (напрямую Grumpy не поддерживает Python C API).URL: https://opensource.googleblog.com/2017/01/grumpy-go-running-...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45816
Как там дела с GIL?
Не внимательно видно статью читали, в ней написано, в частности:Grumpy избавлен от ключевой проблемы Python - глобальной блокировки интерпретатора (GIL, Global Interpreter Lock)
Только GIL - это *не* проблема.
Это фича?
А откуда GIL в Go?
да так и на питоне можно жить теперь получается?
А без питона можно жить ещё лучше. :-)
> А без питона можно жить ещё лучше. :-)Завести гарем жен и меньше вкалывать :)
С гаремом-то как раз почаще прилётся вкалывать :)
Это спасение миллионов пользователей убунты
> Это спасение миллионов пользователей $your_distribution_nameПотому что бидон везде, чёрт бы его подрал. Ну разве что ты используешь исключительно CLI софт. И у тебя не Debian-based дистр. Ибо apt.
В минимальной система он нужен в основном reportbug'у и installation-report'у, apt/aptitude без них будет работать.Но очень быстро приезжает по зависимостям при попытке поставить что-либо ещё, например bind.
Что и винда вся в питоне?
Хуже. Винда вся в дотнете.
А гугл, смотрю, серьёзно взялся за перетаскивание Python-программистов в Go. Уже раньше говорили, что (к сожалению) не столько С++, сколько именно питоновцы мигрируют.
> не столько С++, сколько именно питоновцы мигрируютА зачем плюсерам мигрировать с нормальных шареных либ, которые обновляются отдельно и никого не трогают, на инклуды с гитхаба, которые надо каждый раз обновлять самостоятельно?
> которые обновляются отдельно и никого не трогают
> на инклуды с гитхаба, которые надо каждый раз обновлять самостоятельно?Эм, а первый вариант сам по себе обновляется? А если вы про static/shared, то:
A) есть gccgo
B) есть Go>=1.5: http://blog.ralch.com/tutorial/golang-sharing-libraries/
Сторонние и экспериментальные костыли не интересуют.
Во первых, Go1.5 не экспериментальный (и уже двести лет в обед существует 1.7).
добавлю что в Go 1.8 ещё добавили плагины https://beta.golang.org/pkg/plugin/
Шареные либы не нужны. От них один бардак в продакшене. Гугловцы правильно делают, что навязывают всем статическую линковку.
при обновлении уязвимой системы пересобирать весь софт. логично.
А ещё они при любых проблемах с хостом просто его переустанавливают с нуля. Не надо сову натягивать на глобус.
Cat vs cattle ... (C) Google (кажись)Неужели не читали? Многое бы стало понятнее, почему гугель и другие большие делают так, а не иначе...
> Шареные либы не нужны. От них один бардак в продакшене.Вендузятник должен страдать.
А вот и не соглашусь. Зачем мне теперь изучать Go, если я могу всё написать на питоне на коленке и получить вон какую производительность многопоточность на шару?
для старых проектов, да. А если для новых то уже начинаешь задумываться - если при трансляции кода ты получаешь хорошую производительность и многопоточность, то что будет если писать код напрямую с учётом особенностей самого языка и разрабатываемой программы, естественно результат будет ещё лучше, а если взять во внимание что язык Go довольно легко изучается то желание перейти становится довольно сильным.
1) Потому что примерно с сотни тысяч строк статическая типизация становится крайне важной, да и когда меньше - от неё толк есть.
2) Потому что на Go пишется ровно так же "на коленке" - и при росте популярности его изучение становится вполне выгодным вложением сил.Хотя я вот так и не смог себя заставить плотно за него взяться - уж больно чуждая идеология.
Ещё бы - идеология у Go именно питоновская - довольно ограниченные возможности и хождение строем в плане организации кода, стиля и т.п. В отличие от мультипарадигменных здоровенных, мощных и сложных плюсов, в которых для каждой бочки несколько разных затычек найдётся. То есть для питона замена более чем адекватная выходит, а для плюсов - очень нишевая.
В питоне ничего строго, кроме оформления кода. Питон любят как раз за крайнюю гибкость: в нём можно перерыть все кишки интерпретатора, подгружать модули на ходу, переписывать критические участки кода на C/Cython, а также за полное ООП и прочие плюшки. А Go больше похож на какую-то очень урезанную Яву без исключений.
1) Гибкость - это Perl/C++/D. Да хоть та же Java - с аннотациями там много нетривиального можно сотворить. Питоновкий код куда более прямолинеен. Может, в питоне даже и можно сделать больше, чем обычно - но это будет ни разу не идиоматично. В упомянутых же языках это норма.2) есть, грубо говоря, два подхода. В одном (образно "паскалевском") считается более правильным явным образом писать простыни сравнительно простого кода. В другом (образно "сишном") считается более правильным писать компактный код, состоящий из идиом, которые, в общем-то, требуется один раз понять. Питон и голанг, джава принадлежат к первым, плюсы - ко вторым. Что правильнее - сильно от задачи зависит, в энтерпрайзах первый подход всяко лучше, в ядре - второй.
Гибкость - это не только и не столько возможность написать одно и ту же функцию четырьмя способами.
Ну чисто для примера гибкости, расскажи как в нем сделать класс на основе массива или скаляра, а не структуры(структура с единственным элементом массивом/скаляром за решение не считается). Как обстоит дело с созданием нескольких конструкторов? Можно ли иммитировать другой вариант ООП, например прототипное из js?
Ubuntu весит 1,4 Гб. 800 мегабайт из них - Python. Получается скоро Ubuntu будет весить 600 мегабайт, т.е. снова будет влезать на CD диск
> Ubuntu весит 1,4 Гб. 800 мегабайт из них - Python. Получается скоро
> Ubuntu будет весить 600 мегабайт, т.е. снова будет влезать на CD
> дискЭто как? Эпичное неосиляторство убунтщиков или опять анон заврался? o_O
# %s[bh] The flat size of the matched package, where b is in bytes, and h is in human readable format.
% pkg rquery %n:%sh python27 python34 python36
python27:66.6MiB
python34:78.6MiB
python36:100MiB% pkg rquery %n:%sh $(pkg_deps_all python36)
libffi:124KiB
readline:1.52MiB
gettext-runtime:802KiB
indexinfo:11.5KiB% pkg rquery %n:%sh $(pkg_deps_all python27)
libffi:124KiB
readline:1.52MiB
gettext-runtime:802KiB
indexinfo:11.5KiB
Зависимости забыли посчитать
> Зависимости забыли посчитатьНет, не забыли.
И все же забыли, там под сотню пакетов будет
> И все же забыли, там под сотню пакетов будетА почему не тысяча, ведь гладиолус?
Еще раз, пошагово:
## -d, --dependencies Display the list of packages on which pkg-name depends.
## -s, --size Display the total size of files installed by pkg-name.
% pkg info -s python27
python27-2.7.13_1 32.9MiB% pkg info -d python27
python27-2.7.13_1:
openssl-1.0.2j_1,1
readline-6.3.8
libffi-3.2.1
ncurses-6.0_3% pkg info -d readline libffi ncurses openssl
readline-6.3.8:
indexinfo-0.2.6
libffi-3.2.1:
indexinfo-0.2.6
ncurses-6.0_3:
openssl-1.0.2j_1,1:% pkg info -d indexinfo
indexinfo-0.2.6:% pkg info -s ncurses openssl indexinfo libffi readline
ncurses-6.0_3 10.9MiB
openssl-1.0.2j_1,1 12.0MiB
indexinfo-0.2.6 11.5KiB
libffi-3.2.1 124KiB
readline-6.3.8 1.52MiB
В либах:
% pkg info -B python27
python27-2.7.13_1:
libcrypto.so.9
libreadline.so.6
libncursesw.so.6
libtinfow.so.6
libpanelw.so.6
libssl.so.9
libffi.so.6
> А гугл, смотрю, серьёзно взялся за перетаскивание Python-программистов в Go. Уже раньше
> говорили, что (к сожалению) не столько С++, сколько именно питоновцы мигрируют.А зачем плюсерам мигрировать на язык без возможности управления памятью, без нормальных типов и шаблонов, без нормальных классов, без исключений?
Потому что модно-молодежно, потому что сам Google продвигает
Судя по графику, на одном потоке питон почти вдвое уделывает этот грумпи? Это сам го такой медленный, или транслятор?
А ложка удерживает в 30 раз больше супа, чем вилка. Давайте использовать инструменты по их назначению.
> А ложка удерживает в 30 раз больше супа, чем вилка. Давайте использовать инструменты по их назначению.Кстати, ложкой можно есть всё и без проблем. А вот вилка -- довольно ограниченный инструмент, разве что есть интересное применение -- ткнуть кого-нибудь в глаз. Хотя и здесь ложка справится не сильно хуже.
> ткнуть кого-нибудь в глаз
> ложка справится не сильно хужеДа вы владеете тайным тюремным искусством!
Да, он может сделать так, чтоб ложка удерживать столько же жидкости, сколько и вилка. ЕВПОЧЯ. :-)
> А вот вилка -- довольно ограниченный инструментСпагетти тоже ложкой есть?
>> А вот вилка -- довольно ограниченный инструмент
> Спагетти тоже ложкой есть?Вообще-то, ложка при "правильном подходе" тоже необходима ;)
>ложкой можно есть всё и без проблемЯ посмотрю, как ты управишься с приличным куском мяса.
Девочки не ссорьтесь.Без ножа(pure C), кусок мяса вам будет на посмотреть.
А вот для роллтона нож не нужен...
ну пока это альфа, скорее всего там ещё можно миллион всего оптимизировать (что уже сделано в CPython). Так что надо подождать) чудес не бывает и байткод всегда будет медленнее, чем нативный.
Судя по субъективной оценке сотен тысяч пользователей все питоновские приложения в ubuntu - жручее тормозное лагалово. Помните тот же менеджер приложений, который удалось искоренить большими усилиями сообщества, не давало питоновское лобби. Он больше времени висел, чем работал. И в философии питона 19 пунктов из 20. 20 - это производительность , которая идет в жертву остальным 19.
> Судя по субъективной оценке сотен тысяч пользователей все питоновские приложения в ubuntu
> - жручее тормозное лагалово.А код на сишке от таких же перцев - жручее тормозное падалово. Только не надо опять заливать про низкий порог вхождения питона и недосягаемый сишки - школоту в начале двухтысячных, как раз с общедоступностью интернета, это (как и порог вхождения (n|f|t|m)asm'а) нисколько не смущало, просто заставляло копипастить каркас для гуя-куя и прочее, разбавляя потом копипасту своими чудесатыми шедеврами.
> Помните тот же менеджер приложений, который удалось
> искоренить большими усилиями сообщества, не давало питоновское лобби.Большие усилия сообщества и тайное питоновское лобби? Это случайно не галлюцинации, вызванные отравлением газами при излишне бурном подгорании?
Или те "лоббисты" на самом деле были единственные писатели софта и (будущие, лет через 5) разработчики оного, а все усилия "сообщества" сводились, как на опеннете, к ору недовольных "мы сами ничего не можем, но нам не нравится бидон, а ну живо переделали на труЪ-языке!".> Он больше времени висел, чем работал. И в философии питона 19 пунктов из 20.
> 20 - это производительность , которая идет в жертву остальным 19.mpsyt, zim или ranger говорят об обратном.
Причем последний, даже с кастомными фильтрами-лайнмодами пользователя, почему-то очень ощутимо шустрее того же vifm'a бывает, особенно на больших директориях и с включенными превиюшками. Точнее, рейджер как раз не лагает и не тормозит, в отличие от.
Хотя казалось бы, по логике анонимов и законам их необычного, параллельного-сферического мира, раз vifm написан на труЪшном языке, то все должно быть наоборот.
Спасибо за развернутый комментарий.
И го медленный и транслятор медленный. У четких пацанов уже везде, где нужно, заюзан multiprocessing и использовать транслятор выйдет себе дороже
Но зачем? В Python даже многострочные лямбы не завезли.
Ну вот чтобы переезжать с питона, вестимо
Ну наконец, питон побежден.
Даже Google надоели эти ваши GIL.В масштабах планеты это фейлы.
GIL не такая страшная штука какой вы ее представляете, но если для вас это страшно используйте Jython без GIL
Смотря до скольки ядер масштабировать в пределах нод.
Для обработки запросов используют multiprocessing. Потоки нужны больше для того, чтобы интерпретатор не простаивал из-за I/O .
не страшная? вы ещё раз график посмотрите (особенно ту часть, где видно разницу между 5-ю тредами и 8-ю). java, как я понимаю, увеличивает и без того нескромное использование памяти python вообще до неприличного? да и, например, "местные эксперты" намекают на жуткие тормоза сборщика мусора java, что с этим делать?
Wowza тормозит как не в себе, не кому не рекомендую изучать Oracle(Java)
Не страшная. Потому что есть такие инструменты, как gevent. А у python 3 есть asyncio с uvloop. Или Вы из тех странных людей, которые плодят кучу потоков там, где нет IO?
При правильном применении потоки упрощают поддержку - считай, ещё один способ собрать логически связанный код в одну кучу и получить понятную логику его работы. Примерно по той же причине (в том числе) и микросервисы в моде. да, можно и жуть накрутить - так с асинхронностью это тоже запросто
Еще не побежден, из ubuntu надо выгрести 600 метров мусора
Оставить только ядро и переименовать в ubuntoo.
Интересно будет сравнить с shedskin, компилирующим в C++. Впрочем, в плане фич сразу видно, кто впереди: в гуглобложеке хвастаются возможностью импорта изо всяких __go__.net.http.
> Grumpyhttp://i0.kym-cdn.com/photos/images/newsfeed/000/406/346/fd3...
Ветка на golang-nuts: https://groups.google.com/d/topic/golang-nuts/OJX0TlOF-hw/di...
Всегда говорил, питону не место в продакшине. Но всякие неумехи пихают его просто везде. А благодаря низкому порогу дистрибутивы сегодня завалены кривым кодом школьников. Google молодцы, взялись за решение этой проблемы.
Так они сами себе создали эту проблему. Сейчас вот успешно её решают.
Они использовали тот инструмент что был. Сделали новый, лучше подходящий - теперь переезжать будут. Не спеша, ибо масштабы.
Не тот, что был, а тот, что осилили. В то время уже было много приемлемых вариантов. Сейчас же C++ + QML эталон функциональности и производительности, но нет видимых признаков перехода, т.к. продолжают писать школьники-неумехи-неосиляторы. Вот для них сделали инструмент попроще - Go, чтобы хоть как-то решить проблему.
"Осилили" - то есть он им хоть как-то подходил. Блин, ну не может большая контора опираться только на умников - их может банально не хватить, лишние риски никому на фиг не нужны. А плюсы, да ещё на масштабах - штука сложная, как их не поверни, и для вебовского бакэнда выбор несколько сомнительный. При чём тут QML - вооще не понял, у гугла десктопных апп на питоне я и не помню.
> При чём тут QML - вооще не понял, у гугла десктопных апп на питоне я и не помню.Для нытиков, которые приводят гуи в аргументы питону. А насчет веба, это, имхо, изврат, питон вообще не для него. Для веба есть php, ruby и т.п. специализированные языки.
>А насчет веба, это, имхо, изврат, питон вообще не для него.Как раз для него. Главное, не пихать его в бэкэнд. Ибо Django и Zope. И Flask. И Tornado. Вообще, лёгкие приложения работают на питоне достаточно шустро.
Читал читал и решил таки вставить свои 5 копеек на вашем комментарии.
C++ + QML безусловно штука крутая, но ограниченая со всех сторон. Вы знаете хоть одного человек знающего ВСЕ ньюансы C++, я вот нет... На секунду, я занимался C/C++, с 1997 года. Проблемы с управлением памятью в C/C++ не основные, но массовые, C# и Rust это как раз перезапуск C/C++ именно для устранения этих проблем. Далее опять же с C/C++ это не кросспатформенно ни разу, под каждую платформу надо будет проводить дополнительные оптимизации и доработки, а если используются сторонние либы и их дофига, то это надолго. Даже сейчас на платформу с Risc-V не портировано и части софта написанного на C/C++. А что тогда остается?
Остается как раз питон, который без мыла пролез везде... и GO, который как питон, но с человеческим лицом. Оба языка без проблем работают на любых платформах, без проблем свойственных C/C++. Единственная проблема GO, это как раз отсутствие нормального аналога QML для GUI (все работает либо через связки, либо использует C/C++ что зачатую, собственно ставит крест на мультиплатформенности).
Опять же если говорить про GUI, я не вижу ни одного цельного продукта позволяющего создавать приложения цельно под все платформы, кроме QT Creator. Но опять же QT это C/C++ работа с другими языками через связки-подвязки, что не удобно. Да и к самому QT Creator вопросов много, выглядит он как привет из 90х, как УАЗ буханка, которая сразу получилась идеальной... И создавать в нем интерфейсы безусловно можно, но не приятно.
Итог такой C++ + QML, это скорее для тех кто несмотря ни на что и вопреки всему... а не для простых людей.
пихаю школо-код в продакшен. Согласен, что
Google молодцы, взялись за решение своей, и исключительно своей психологической, проблемы.
И что питон получил очередной инструмент при желании портировать часть кода в golang. На Tiobe между ними пропасть, по деньгам, и тем более по количеству предложений еще более скромнее golang смотрится. Все в гугл не попадем думаю, манйстримная школота по крайней мере остаеться пока на Питоне ) А если и дергаться немножко параллельно куда, так на ноду.
А чуток в будущее заглядывать религия не велит? Надо всегда в догонялки играть?
А куда заглядывали те, кто совсем недавно восторженно бегал с гугловским Dart?
В моем мире golang уже свою нижу занял, где-то между Ruby и Swift. Зачем туда заглядывать?
Питон же после java, c/c++ на почетном 3 месте, уже спихнув c# с бронзы. Будущее уже наступило.
> А куда заглядывали те, кто совсем недавно восторженно бегал с гугловским Dart?Почему-то вспомнился фильм "human centipede".
А завтра оно станет прошлым. Я ж о том и говорю - тренды надо смотреть.И ниша - это не "между", это конкретная сфера применения. Да, для go она уже определилась - "стандартный" софт средней сложности, прежде всего сетевой. То есть это ровно та ниша, где продакшн-питон и живёт.
Дарт - хреновый аналог. Чем дартоверы думали - понятия не имею, вроде ж довольно быстро понятно стало, что не взлетит - в браузере может выжить только консенсусное решение - вот тот же WebAssembly взлететь практически обречён. И уж точно это стало понятно до того, как там появилось, что изучать. А здесь - платформа не ограничивает никак.
Этo не психoлoгическая прoблема Google. oчевиднo всем, крoме Вас, чтo прилoжения на питoне дo ужаса тoрмoзные и жрущие память. Пoмните какoй скандал был с менеджерoм прилoжений ubuntu? Пoвальные тoрмoза вo всех прилoжениях - этo прoблема именнo питoна.
Некoтoрые пишут чтo питoн тoрмoзит из-за разрабoтчикoв, кoтoрые в нем тoлкoм не разбираются. Нo этo, oпять же, прoблема языка. oн пoзвoляет вытвoрять такoе.
И самoе неприятнo - ничегo если бы шкoльники дрли свои лабы у себя дома. Но нет, всё это пoделие вываливают в продакшн, пихают во все дистрибутивы линукса, всё тормозит и портит репутацию linux в конечном итоге.
Да, мы на всё пойдём,чтобы доставить тебе больно.
Место, но не там. Управляющие скрипты, системы сборки/развёртывания/бэкапа и тому подобное - вполне для него.
Школьные лабы, домашние сервачки ему предел
Да что угодно тысяч до 10 строк и не требующее какой-то особой производительности. Дальше - смотреть надо по ситуации.
> Управляющие скрипты, системы сборки/развёртывания/бэкапа и тому подобное - вполне для него.Нет.
>> Управляющие скрипты, системы сборки/развёртывания/бэкапа и тому подобное - вполне для него.
> Нет.Да.
На sh\ksh\tsch\bash после определённого размера становится просто больно это писать. Тут уж в зависимости от твоих "корней" - либо в питон, либо в перл. ТЧК.
> ... в зависимости от твоих "корней" - либо в питон, либо в перл. ТЧК.В оригинале было ещё tcl ... но я его уж лет "в живую" 10 не встречал :(
Рано радуетесь. Битон на столько въелся в дистрибутивы, что я думаю еще не скоро будет искоренен
> Рано радуетесь. Битон на столько въелся в дистрибутивы, что я думаю еще
> не скоро будет искорененИ не будет. Примерно как и perl.
Какой-то минусятор не согласен, а ведь всё именно так
А можно объективно и тезисно, почему Python настолько ужасен, что тут все так его раскритиковали?
Низкая производительность, ибо JIT пока не завезли, и отсутствие нормальной многопоточности, ибо GIL. Всё остальное - субъективщина.
Спасибо. Да c этими минусами трудно поспорить
производительность и JIT в python есть, но завезли их только в PyPy. он хоть и отстаёт по фичам, но большинству его хватит (если не используете C-ные либы, то совместимость будет около 100%).
Еще большое потребление памяти, что обусловлено архитектурными особенностями. И чтобы приложение работало с терпимой скоростью - надо воротить костыли. Ну т.е. этот язык 100% заточен на удобство программирования.
Только на opennet измеряют производительность не приложений, а самого языка, причем в таких идиотских единицах измерения:- одна нежить (неJIT)
- один неигил (неGIL)По-сути - это наименее разумный способ проводить время - сравнивать скорость языков. Python настолько туп и прекрасен в своей простоте и ясности кода, что попытки его изменить - делают его только лучше. Все эти Go - только упрочат популярность самого Python-а.
И еще - предлагаю внести в матофильтр слово продакш[е]н - никто не значет что еэто такое, но все пользуются как универсальным доказательством как непригодности "для чего-то", так и исключительного соответствия "непонятно чему".
Питон и производительность не совместимы. Почитайте философию: https://ru.wikipedia.org/wiki/Python
Python - язык для красоты и удобства. Никто в тормозах именно его не упрекает, это вполне ожидаемо и нормально. Проблема начинается тогда, когда приложения на нем пихают в продакшн, во все дистрибутивы линукса и вообще везде, где попало. В придачу к найтивной тормознутости языка из-за низкого порога код пишут школьники-неумехи, что сказывается на его качестве в худшую сторону. Сюда же стоит добавить огромный вес библиотек, около 500 мегабайт. Программисту всё это удобно, а пользователю нет. И таких эгоистов становится всё больше.
> Сюда же стоит добавить огромный вес библиотек, около 500
> мегабайт.
> 500 мегабайт.
% pkg info -s python27
python27-2.7.13_1 66.6MiB
% pkg info -s $(pkg info -dq python27)
libffi-3.2.1 124KiB
readline-6.3.8 1.52MiB
gettext-runtime-0.19.8.1_1 802KiB
Хотя да, подоконники должны страдать.
У "подоконников" распакованная стандартная библиотека ~100 Мбайт. А человек, писавший про 500 - до сих пор считает что прав именно он.
> У "подоконников" распакованная стандартная библиотека ~100 Мбайт. А человек, писавший
> про 500 - до сих пор считает что прав именно он.Ладно, разрешаю не страдать ;), но что там намутили в убунтах, я не знаю.
Дефолтный 2.7 - 66 MiB, причем - там и idle (типа "IDE") и тесты всякие.
А вот если собрать его без 2to3, idle, использовать по возможности системные библиотеки (--enable-shared --without-ensurepip --with-system-ffi) и прогнать тесты после сборки, но не добавлять их в пакет для пользователя, то на выходе будут:
% pkg query %sh python27
32.9MiB
Да и зависимости вполне нормальные:
% pkg query %dn python27
openssl
readline
libffi
ncursesДефолтный Python3.5 - 101MiB
после выкидывания тестов и idle:
% pkg query %sh python35
43.6MiB
зависимости:
% pkg query %dn python35
openssl
readline
libffi
ncurses
Ну а для минимального пакета можно глянуть в список файлов "embeddable zip" или в дебиановские пакеты python-minimal и libpython-minimal.И да, сама сборка занимает на стареньком ноуте от силы пару минут и на ракетные технологии совсем не тянет. А кто не хочет собирать сам, может попытаться повлиять на мейнтенеров своего любимого дистрибутива - все больше толку, чем просто ныть на форумах, как пара анонимов выше.
>В придачу к найтивной тормознутости языка из-за низкого порога код пишут школьники-неумехи, что сказывается на его качестве в худшую сторону.В общем-то эту проблему на данный момент удалось решить только ML-подобных языках. У всех остальных слишком низкий порог вхождения. Даже в С++.
В "философии" P. нет ни слова про замедленную производительность. И что, у нас еще один супер-критерий - содержание "философии"?Не в ней ли сосредоточена самобичующая самооценка про так часто здесь упоминаемый "низкий" порог? Вы считаете asincio, scipy, odoo итп признаками низкого порога? А может низкого интеллекта?
Так у Ассемблера философии вообще нет. Нет её и у BAT/VBS/WSH/PowerShell, которые работают на одном том же коде в 5-10 раз медленнее, при этом не перестают быть самыми популярными скриптовыми языками под Windows.
Упрекать Python его же стандартной библиотекой (100 Мб), умеющей почти всё - это апофеоз демагогии.
В философии вообще ничего нет про скорость. Философия ориентирует язык на удобство(!!!), и даже там, где это идут в ущерб производительности. И он не стал медленным в какой-то момент. Это изначально так планировалось и реализовано.
Удивляют вообще эти люди, дают им хороший рабочий инструмент, ваз 2110, а они из него бугатти требуют сделать. Дак возьми с++ и будет тебе хоть целый боинг.
У него низкой порог, теперь не пользоваться им что ли? У php до 7 тоже низкий порог, все успешно пользуются, применяют по назначению и вполне довольны.
> У него низкой порогДа, хоббиты и прочие гномы оценили.
Такое ощущение, что у go все же есть проблемы с адаптацией в отрасли.
А есть хоть один дистр без питона?
Почти нет, ибо он постепенно занимает нишу Perl'а. Ждём ответа от Prel 6!
> А есть хоть один дистр без питона?Да. Например, дистрибутивы BSD.
Способный нормально работать без питона или вообще не имеющий пакетов питона в репах? Если первое, то их хватает, если второе, то только что-то очень экзотическое.
Теперь буду клиентам и студентам рассказывать про то что философская "ориентация языка на удобство, даже в ущерб производительности" означает преднамеренно запланированный и реализованный JIT и GIL. Вот они-то будут рады! Может напомнить достопочтенной оппонирующей аудитории в чем у этих досадных механизмов есть преимущества?А если серьезно - давайте поспорим: вычисление чисел Фибоначчи на Питоне будет не более чем на 50% медленнее, чем на любом из 90% языков первой по популярности двадцатки языков. Но время разработки любого более-менее сложного алгоритма на Питоне будет в разы быстрее именно из-за его ущербной "философии". Правда, поверят в это только "апологеты" языка - а это, судя по топику, вымирающий вид, мыши, неспособные прогуглить скорое затопление корабля, кишащего Змеями...
Очень жаль, друзья, что мы все очень ревностно отстаиваем собственные предпочтения в языках. Знать их много, да еще и с реальной полезностью в жизни - невозможно. А разговаривать на смеси двух и более - почему-то считается зазорным.
Программируйте на Питоне - не смотря ни на что! Это красивый и простой язык, на котором приятно кодить и шкодить.
А выбирая что изучать из языков программирования по "рейтингам" - помните про 1С, - это, увы, реалии, о которых на очень уважаемом мною opennet.ru - можно не увидеть новостей годами. Хотя это свободная (и бесплатная, не спорьте) среда программирования, занимающая уверенно 1-е место и целых 80% вакансий программистов. Вот так-то...
Ах да, я не увидел еще одну проблему - Python, оказывается, пихают во все дистрибутивы! Куда смотрит ФАС и туловище(с). Сжечь их и его! ... Правда, мы это уже много раз проходили.
Кстати, можно хоть один реальный пример "школо-кода в продакшене"? Только предупреждаю - прорефакторим его вместе. Но критерий "хорошести", чур, один - единственно объективно измеряемый: на 50% лучшая скорость выполнения. Поэтому любителей функций, структурного программирования, массивов, нелюбителей меток итп - ждет разочарование: часто всё это ускоряет код, если есть определенность в коде, не-равноверятность условий, предсказуемость в множествах. ВО всех этих случаях то, что придумает неправильный программист или просто человек, который умеет "крыжить" - будет быстрее.
> Grumpy нацелен на использование в качестве прозрачной замены CPython 2.7
> 2.7Ага, ещё десяток лет тащить будут.
Потом гугл по привычке всё выбросит, и займётся новыми костылями. Тоска.
Странно это. Пистон вон тоже 2.7-совместимый.
Ничего странного -https://github.com/dropbox/pyston#current-state
> Current state
> Pyston should be considered in alpha: it "works" in that it can successfully run Python code, but it is still quite far from being useful for end-users.
> Currently, Pyston targets Python 2.7, only runs on x86_64 platforms, and only has been tested on Ubuntu. Support for more platforms -- along with Python 3 compatibility -- is desired but deferred until we feel successful on our initial platform. Pyston does not currently work on Mac OSX, and it is not clear when it will.Оба проекта находятся в состоянии альфа-версии, у авторов того и другого проекта тонны кода на python 2. И тем и другим нет смысла тратить силы на поддержку ненужного им python 3.
