> [...]
> Насколько я понимаю, это аргументы в ту же сторону, куда и Вы
> клоните? Но тогда что от этого меняется?
> [...]
> То есть Вам по факту пофиг, будут green threads или один движок
> событий. Тогда при чём тут Питон?Вообще весь тот разговор о libpth я рассматривал как эдакий оффтопик. Он был эдаким вольным рассуждением на тему "почему же apache вручную возится с select/poll не используя libpth взамен". Мне казалось, что оффтопичность сего достаточно очевидна и допустима. Видимо ошибался.
>>>[...]
> Ну кому "скучный и безликий", а кому отличная рабочая лошадка, при этом
> приятная и удобная. В отличие от Ruby, который требует выворота мозгов,
> который не окупается.
Вы хотите сказать о том, что мэйнстим как всегда ездит по проторенной дорожке боясь свернуть в сторону? Я знаю это. И все, по-моему, знают. И даже причины тому известны. Скучны и неинетересны ибо обсуждались тысячи раз.
>>> Модуль multiprocessing находится [...]
> А чем это отличается от передачи данных между тредами? Там такое же
> SHM и та же синхронизация. Только в случае тредов вся память
> зашарена насильно, а в случае процессов это надо делать явно.
> (Нет, я, конечно, знаю, где отличия. Но для обычной питоновой роли они
> малосущественны.)
Явно надо указывать, что создавая объект надо выделять его из SHM кучи, а не из локальной. При необходимости передать открытый файловый дескриптор надо прибить дочерний процесс и создать новый. Когда приспичит подгрузить библиотеку, надо подгружать её в каждом процессе, а не во всех сразу.
Это достаточно существенные отличия, накладывающие ограничения на допустимые подходы к проектированию кода. Причём, на мой взгляд, искусственные и ненужные ограничения.
>> [...]
> Ваша постановка задачи в виде "три процесса по 25 kernel-space потоков" уже
> намеренно натянута, как те "тендеры", которые рассчитаны ровно на одного производителя
> и одного поставщика.
Это просто один из примеров. Вполне реальный пример. Дополнительная демонстрация на ограничения накладываемые отсутствием kernel-space thread'ов в python'е.
>> И как это чудо прикрутить к скриптам, которые мне иногда приходится писать
>> в LibreOffice?
>> Cython -- это же уже не питон. [...]
> Если для них не критична скорость - так пусть остаются. В чём
> проблема-то?
> Я плохо представляю себе, честно говоря, необходимость, например, высокой математики в
> libreoffice.
Вообще-то, типизация переменных (из-за которой начался разговор про Cython), в моём понимании для скрипт языка в первую очередь средство программирования/отладки, нежели способ увеличить эффективность байткода. В случае работы с calc, например, очень приятно было бы типизировать переменные, чтобы попытка взять из ячейки строку и положить в переменную типа int выкидывала бы исключение, которое я обрабатывал бы промеж прочих исключений, не засирая код тучами явных проверок типов. А если бы, при этом, python поддерживал бы типа вида {целое в диапазоне от 5 до 17} то это было бы вообще супер. А если бы он поддерживал типы, когда я в качестве типа мог бы указать предикат проверки принадлежности типу... Да я бы задвинул на всё остальное и писал бы на python'е. Шутка, конечно, но как всегда, доля правды в ней есть.
Но Python не только не поддерживает типы задаваемые предикатами, он вообще не поддерживает типизацию переменных. Он не поддерживает объявление переменных, например с целью автоматического отлова ошибок типа очепятка_в_имени_переменной. И шансов на изменение ситуации к лучшему нет никаких.
А то, что статическая типизация, подчастую позволяет компилятору генерировать более эффективный код, с моей точки зрения, для интерпретируемого языка просто дополнительная бесплатная плюшка. И да, иногда, даже в скриптах для libreoffice эта плюшка могла бы быть экстремально полезной. Когда начинается какая-нибудь возня в таблицах, с переборами вариантов как можно переставить элементы этих таблиц получше... Там вообще-то NP-hard проблема была, проблема составления расписания, но кое-что сделать можно было, чтобы поменьше телодвижений совершать вручную. И кое-что я сделал. Но ограничение на глубину рекурсии выбиралось из соображений "чтоб гуй не залипал в тормозах". Как вы понимаете, статическая типизация могла бы немало помочь. Допустим в SBCL добавление в код указания типов переменных может увеличить скорость выполнения в 2-3 раза. Правда SBCL компилирует в native код, но всё же.
>>> Там есть странные вещи, но, о чём Вы говорите, давно и успешно
>>> решается. Просто надо знать чуть шире, чем одно базовое средство.
>> Я бы поверил Вам на слово. Если бы речь шла не о
>> Python'е. На заре своего существования, он был слишком увлечён противопоставлением себя
>> Perl'у. Это фатально на нём сказалось.
> Простите, я не понимаю, откуда у Вас такие выводы. С Perl они
> стартовали (как самостоятельные языки) ноздря в ноздрю, но развивались совершенно без
> оглядки друг на друга где-то до середины 90-х.
Да неужели?
http://en.wikipedia.org/wiki/There%27s_more_than_one_wa...
http://www.python.org/dev/peps/pep-0020/
Вторая ссылка сама по себе показательна, и набор фраз там очень напоминает сутру "мы делаем перл, но наоборот". При этом, для наглядности, я явно одну из фраз процитирую здесь: "There should be one-- and preferably only one --obvious way to do it." =)
> И, кстати, при чём тут однобокая развитость к вопросу о наличии Cython?
> Что, для Perl есть вариант написания со статической типизацией, компилируемый в
> эффективный машинный код?
Дискуссия эта не равносильна дискуссии "почему python лучше perl'а". Я высказал своё мнение, чем плох Python. Про перл я выше упомянул лишь к слову о том, что... В общем, Perl и Python они находятся в некотором смысле на двух противоположных концах доведения идеи до абсурда. Или излагая свои мысли чуть иначе, я бы сказал, что Perl и Python исповедуют во многом противоположные идеи, но одну идею -- доведение идеи до абсурда -- они оба признают как основополагающую.
>> То есть он достаточно приятный
>> язык, допустим PHP в разы хуже и неудобнее. Но и всё
>> же, он далёк от идеала.
>> По-крайней мере существенно дальше, чем ruby.
> Для Вас Ruby близок к идеалу? Извините, но jIMHO Ruby это достаточно
> однобокая поделка на тему "мы тут попытались сделать функциональную ориентированность
> через <strike>задницу соседа</strike> объектную ориентированность, причём записать
> это всё по-японски, чтобы круче выглядело".
Вполне себе honest opinion, я так и не понял, зачем, прежде чем высказать его, вы заранее испрашивали извинений.
