| 1.1, oxyum (ok), 00:06, 12/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А если использовать указания типов, то можно повысить производительность в разы, правда тогда от синтаксиса python остаётся не так уж и много, но всё равно расширения гораздо проще чем на pure-C писать.
| | |
| |
| 2.2, gegMOPO4 (ok), 00:11, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Без генераторов и некоторых других вкусных питонизмов это всё было совсем не интересно.
| | |
| |
| 3.3, oxyum (ok), 00:13, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
ой, да бросьте вы, когда действительно важна скорость и на голом асме писать будешь, вопрос только в том, под какой проц писать этот самый код на асме?!
| | |
| |
| 4.15, gegMOPO4 (ok), 15:54, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
Последний раз пробовал версию 0.11. Писать в привычном питоновском стиле оказалось невозможно, то то не поддерживалось, то это. В результате гипотетическое ускорение оказалось не стоящим ясности и краткости кода, да и обычный Питон как раз теми средствами, что отсутствовали в Cython, хорошо поднимал производительность. Если догнали Питон по фичам — хорошо, нужно будет ещё посмотреть. Но что-то разработчики CPython не проявили энтузиазма на недавнее предложение писать оптимизированные версии стандартных модулей на Cython. Не воспринимают его пока всерьёз.
| | |
|
|
|
| 1.4, langer (?), 04:26, 12/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
Мне в Питоне многое нравилось.
Не нравилась только его прагматика. - Держать скомпилированный байткод рядом с исходниками. Это не UNIX-way. Именно поэтому я его и бросил.
Или уж только исходники. Как в Ruby или JS.
Или бинарники должны лежать отдельно.
Например, как это сделано в Erlang.
Или в той же java. Только в java другая болезнь - каждый проект тащит свой набор библиотек. Ну да с ней все понятно - она полувиндовая была сразу.
Но что мешало в Питоне это сразу сделать грамотно?
Хотя по идее это только вопрос перепаковки дистрибутива и небольших патчей на ядро, чтобы он брал бинарники из отдельных путей.
Надеюсь, что кто-нибуть такой проект сделает. Или может это уже в других реализациях есть.
| | |
| |
| 2.7, matte (?), 09:51, 12/08/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Или уж только исходники. Как в Ruby или JS.
В Руби тоже есть байткод, и он тоже лежит рядом с исходниками, только эта фича выключена по умолчанию.
| | |
| |
| 3.11, langer (?), 11:48, 12/08/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> В Руби тоже есть байткод, и он тоже лежит рядом с исходниками, только эта фича выключена по умолчанию.
Ну видимо кто-то из девелоперов Руби пытается эту дурную традацию лоббировать.
Благо что здравый смысл пока побеждает.
Если уж решили делать отдельный байт-код, то нужно его держать отдельно от исходников.
А не идти на поводу у виндузятников в UNIX-системах.
Тем более, что сделать нормальную организацию файлов гораздо легче, чем реализовать сам байт-код.
| | |
|
| 2.8, all_glory_to_the_hypnotoad (ok), 10:05, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
 в 3ей версии он кладёт байткод в отдельную поддиректорию, но всё равно вместе с исходниками. Собственно, от байткода в питоне по сути только название, фактически это те же самые исходники в бинарном виде.
| | |
| |
| 3.10, langer (?), 11:42, 12/08/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Собственно, от байткода в питоне по сути только название, фактически это те же самые исходники в бинарном виде.
Тем более.
| | |
| |
| |
| 5.20, langer (?), 19:01, 12/08/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> что тем более? бинарник грузится в разы быстрее
Какую часть по-вашему составляет суммарное время загрузки питоновского кода от суммарного времени работы приложений на питоне?
Тем более, что каждый модуль грузится только один раз. (Если не был сделан принудительный reload, что встречается крайне редко в основной массе кода.)
И все это безобразие в файловой системе только ради того, чтобы модули грузились быстрее.
| | |
| |
| 6.26, all_glory_to_the_hypnotoad (ok), 22:18, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Какую часть по-вашему составляет суммарное время загрузки питоновского кода от суммарного времени работы приложений на питоне?
это зависит от приложения, где-то может составлять значительную часть. Так же не стоит забывать, что даже простое приложение может грузить сотни файлов с кодом из библиотек.
| | |
| |
| 7.30, langer (?), 23:17, 12/08/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Какую часть по-вашему составляет суммарное время загрузки питоновского кода от суммарного времени работы приложений на питоне?
> это зависит от приложения, где-то может составлять значительную часть. Так же не стоит забывать, что даже простое приложение может грузить сотни файлов с кодом из библиотек.
Если программа грузит сотни файлов кода, то обычно рассчитывается, что и работает она достаточно долго.
Если программа грузится однократно, то это тоже не проблема, какое бы она время не работала.
Если же по каким-то идиотским причинам программа на Питоне перезагружается в цикле из шелл-скрипта со всеми своими библиотеками и работает меньше, чем грузится, тогда обычно пишут загрузчик на самом Питоне в пару строк, который в цикле вызывает остальной код.
Модули-то загружаются однократно. Эта фича ведь в Питоне существует.
В-общем, нет никаких оправданий для этого маразма с дублированием одного кода в разных форматах.
А если уж решили делать отдельно файлы с байт-кодом, то нужно было их раскладывать, как это положено в UNIX. Методика эта проверенная, и ничего изобретать тут не было нужно.
| | |
|
|
|
|
|
| 2.14, anonym (?), 14:33, 12/08/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Насколько я понимаю, в Питоне байткод создаётся для импортируемых модулей, чтобы быстро импортировалось. Байткод одинаков для Linux/Windows/MacOS. Зачем его хранить по "Unix-way"?
| | |
| |
| 3.19, langer (?), 18:55, 12/08/2011 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Насколько я понимаю, в Питоне байткод создаётся для импортируемых модулей, чтобы быстро
> импортировалось. Байткод одинаков для Linux/Windows/MacOS. Зачем его хранить по "Unix-way"?
Ответ нахотится в вашем вопросе. "Linux/Windows/MacOS" - два против одного.
Или вы не видели систем, сделанных в соответсвии с UNIX-way, которые при этом были портированы в Винды.
Тем более, что виндоводам обычно по барабану где что лежит, так что их интересы при этом никак не пострадают.
| | |
| |
| 4.23, anonym (?), 21:22, 12/08/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
ты просто путаешь разные подходы для разных языков. Питон - скриптовый язык он работает из текстового файла. Байткод создается автоматически для некоторого ускорения работы, не является скомпилированным файлом как в C/C++. Тут нету понятия исходный код и бинарники. нету никакого смыла ему лежать где либо ещё.
Засрал всю тему своей идиотической претензией.
| | |
| |
| 5.24, langer (?), 22:03, 12/08/2011 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> ты просто путаешь разные подходы для разных языков.
То что у него именно другой "подход" - я это прекрасно понимаю.
> Питон - скриптовый язык он работает из текстового файла.
То есть вы считаете, что скриптовые языки - это такие, которые "работают из текстовых файлов". Именно так вы понимаете отличительную особенность скриптовых языков.
И "подход", используемый Питоном, - это по-вашему не "подход" самого Питона (точнее его создателей), а "подход" абсолютно всех скриптовых языков.
Только вот незадача. Если модуль загружен из файла с байт-кодом, то как же он тогда "работает из текстового файла".
> Байткод создается автоматически для некоторого ускорения работы,
Ну да, и в случае с Питоном байт-код "автоматически" лежит в системных каталогах с правами только на чтение.
Видимо вы привыкли б..кодить с правами рута на все. Или вообще из-под Виндов Питон юзаете.
> не является скомпилированным файлом как в C/C++.
Значит вы считаете, что если не происходит компиляции в машинный код, то по-вашему вообще не происходит никакой компиляции, и файл с байт-кодом по-вашему не является скомпилированным файлом.
И видимо вы уверены, что в языках, где нет файлов с байт-кодом, там по-вашему вообще байт-кода нет, как и компиляции.
> Тут нету понятия исходный код и бинарники.
Значит для вас файлы с байт-кодом Питона бинарниками не являются.
> нету никакого смыла ему лежать где либо ещё.
В вашем понимании смысла - это действительно так.
> Засрал всю тему своей идиотической претензией.
Это неудивительно, что с вашим пониманием отличительной особенности скриптовых языков, как "работы из текстовых файлов" - подобные претензии вам кажутся "идиотическими".
--------------------------
По крайней мере можно сделать вывод, в угоду какой аудитории основная реализация Питона разрабатывается.
Остается надежда, что может быть в альтернативных реализациях не будут так гнаться за ширпотребностью.
Благо, что на Питоне свет клином не сошелся.
| | |
| |
| 6.28, anonym (?), 22:30, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Только вот незадача. Если модуль загружен из файла с байт-кодом, то как же он тогда "работает из текстового файла".
http://docs.python.org/tutorial/modules.html
байткод создается автоматом при импорте модуля, при этом используется время модификации текстового файла (.py), если оно не совпадает с байткодом (.pyc), то последний будет проигнорирован.
Питон - интерпретируемый язык. В этом его преимущество и недостаток. Программу на Питоне не нужно компилить. С байткодом программа не работает быстрее, но считывается байткод быстрее чем текстовый.
| | |
| |
| 7.29, langer (?), 23:05, 12/08/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
>>Только вот незадача. Если модуль загружен из файла с байт-кодом, то как же он тогда "работает из текстового файла".
> http://docs.python.org/tutorial/modules.html
>
> байткод создается автоматом при импорте модуля, при этом используется время модификации текстового файла (.py), если оно не совпадает с байткодом (.pyc), то последний будет проигнорирован.
Я знаю, как импортируются модули в Питоне.
Ну и? А если ".pyc" не будет проигнорирован? Как модуль будет по-вашему "работать из текстового файла". Видимо ваше сознание просто не способно обработать обе ветки конструкции "если-то-иначе".
Ах, ну да, в приведенной вами цитате альтернатива была опущена. И вы радостно решили, что видимо байт-код будет игнорироваться всегда. А зачем он тогда нужен? А вот! В конце вы даете свою трактовку, зачем по-вашему.
Похоже вы только сейчас начали лихорадочно читать документацию, да и то понять не можете, что там написано.
До этого вы заявили буквально следующее: "Питон - скриптовый язык он работает из текстового файла". Продемонстрировав, как вы понимаете, что такое скриптовые языки.
> Питон - интерпретируемый язык. В этом его преимущество и недостаток.
Еще лучше. Теперь оказывается Питон в вашем понимании внезапно перестал быть скриптовым и стал интерпретируемым.
> Программу на Питоне не нужно компилить.
Ну я понял уже, что вы убеждены, что при создании байт-кода никакой компиляции не происходит.
> С байткодом программа не работает быстрее, но считывается байткод быстрее чем текстовый.
Вообще замечательно. Оказывается с байткодом программа по-вашему не работает быстрее, а просто быстрее считывается. Ухаха.
Вот я и говорю. К сожалению видимо главная реализация Питона рассчитана именно на такую аудиторию. Может быть другие реализации будут учитывать интересы в первую очередь профессиональных разработчиков.
| | |
| |
| 8.31, anonym (?), 23:22, 12/08/2011 [^] [^^] [^^^] [ответить] | +1 +/– | Ну а какой тут конфликт в том что он скриптовый и интерпретируемый Видишь ли, б... текст свёрнут, показать | | |
| |
| 9.33, langer (?), 23:38, 12/08/2011 [^] [^^] [^^^] [ответить] | –2 +/– | Ну то есть он по-вашему никак не компилируемый Я уже понял вашу точку зрения К... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 2.16, gegMOPO4 (ok), 16:01, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
Что текстовые исходники, что бинарный байткод — всё это архитектурно-независимые ресурсы, с точки зрения Unix разницы между ними практически нет. Ну да, можно байткод хранить в /var/cache (если есть исходники, он всё равно генерируется при инсталляции), только зачем? Что он генерируется? Ну так часть ресурсов тоже генерируется, например ядерные модули-посредники для проприетарных драйверов, шрифты, каталоги, символические ссылки.
| | |
| |
| 3.18, langer (?), 18:47, 12/08/2011 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Что текстовые исходники, что бинарный байткод — всё это архитектурно-независимые ресурсы, с точки зрения Unix разницы между ними практически нет. Ну да, можно байткод хранить в /var/cache (если есть исходники, он всё равно генерируется при инсталляции), только зачем? Что он генерируется? Ну так часть ресурсов тоже генерируется, например ядерные модули-посредники для проприетарных драйверов, шрифты, каталоги, символические ссылки.
То есть вы считаете, что хранить байт-код в /var/cache - это и есть UNIX-way.
"с точки зрения Unix" есть еще организация файловой системы. Просто вы об этом мало что знаете.
Подавляющее количество байт-кода Питона не генерируется в runtime. Но вы почему-то решили, что дело именно в этом. Ту малую часть, что генерируется можно действительно положить в var, но только не в /var/cache, потому что это не кеш.
Хотя, действительно, питоновский байт-код ведет себя скорее как кеш. Что и сбивает с толку тех, кто начали изучение программирования с Питона.
| | |
| |
| 4.21, gegMOPO4 (ok), 19:20, 12/08/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Спасибо, что просвещаете воображаемый образ собеседника. Буду рад узнать и о других приписываемых мне вами заблуждениях.
Если вы что-то слышали о FHS, может быть объясните, в чём с его (как вы это понимаете) точки зрения отличаются текстовые исходники и бинарный байткод установленных модулей и скриптов Питона и где им место?
| | |
| |
| 5.22, langer (?), 19:37, 12/08/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
>Спасибо, что просвещаете воображаемый образ собеседника. Буду рад узнать и о других приписываемых мне вами заблуждениях.
>
> Если вы что-то слышали о FHS, может быть объясните, в чём с его (как вы это понимаете) точки зрения отличаются текстовые исходники и бинарный байткод установленных модулей и скриптов Питона и где им место?
То есть вы "что-то слышали о FHS", но при этом считаете, что с этой точки между исходниками и байт-кодом разницы нет. Также вы считаете, что с точки зрения FHS лучшее место для байт-кода - это по-вашему /var/cache.
Подсказка 1. Посмотрите как это сделано в языках, которые имеют качественную поддержку байт-кода, и при этом соответствуют идеологии UNIX.
Подсказка 2. Не ищите ответ там, где ищут "миллионы мух".
| | |
| |
| 6.25, gegMOPO4 (ok), 22:12, 12/08/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Услышим ли мы ваше мнение, а не разоблачение ваших фантазий, приписываемых другим?
| | |
|
|
|
|
| 2.40, анонимус (??), 02:40, 13/08/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Если *.pyc уж так уж мешают, то можно сделать export PYTHONDONTWRITEBYTECODE=yes
А ещё можно удалить *.py и оставить только скомпилированный байткод.
Только не понятно зачем: какая разница, что лежит в lib/python/site-packages/* ?
| | |
| |
| 3.41, langer (?), 07:00, 13/08/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
Во-первых, вы ничего не поняли. Они не мешают, они лежат не на своем месте.
Причем, не столько *.pyc, сколько *.py при наличии *.pyc.
> Если *.pyc уж так уж мешают, то можно сделать export PYTHONDONTWRITEBYTECODE=yes
Да, на текущий момент, это решение. Только не во всех пакетных дистрибутивах опять-таки от *.pyc легко избавиться.
Правда я уже говорил, я на данный момент нашел для себя решение еще лучше.
Стараться не использовать Питон, и убирать его ото всюду, откуда можно.
> А ещё можно удалить *.py и оставить только скомпилированный байткод.
А это будет работать со всеми библиотеками/фреймворками?
Вы проверяли? Это поддерживается?
> Только не понятно зачем: какая разница, что лежит в lib/python/site-packages/* ?
Вы забыли еще про lib/python/*
Если вам не понятно и нет разницы, то это действительно вас не должно волновать.
Так же как вам, судя по всему, не будет разницы, если в каких-то реализациях Питона это будет сделано по-другому.
И вообще, как было сказано в начале поста, вы не правильно поняли суть вопроса.
А если вам нет разницы, и вы не понимаете проблему, зачем давать пустые советы?
Чтобы казаться умнее?
| | |
|
|
| 1.13, арсен (?), 13:40, 12/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Решительно бред. Удали исходники, оставь байткод. Не пойму в чем проблема даже. Или тебе надо чтобы принципиально байткод лежал в другом каталоге? На Земле сотни тысяч программистов, ну вот это одна из фантазий одного из них... Напиши GvR о ней...
Проблема есть, она в том, что байткод крайне сложно защитить от реверс-инжениринга, а не в том где что лежит...
| | |
| |
| 2.17, langer (?), 18:35, 12/08/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Решительно бред. Удали исходники, оставь байткод.
Это решение поддерживаемое?
> Или тебе надо чтобы принципиально байткод лежал в другом каталоге?
Мне надо, что бы это принципиально соответствовало принципам UNIX.
Точнее чтобы была возможность привести в соответсвие с этими принципами для тех, кому это надо.
> Не пойму в чем проблема даже.
> На Земле сотни тысяч программистов, ну вот это одна из фантазий одного из них... Напиши GvR о ней...
> Проблема есть, она в том, что байткод крайне сложно защитить от реверс-инжениринга, а не в том где что лежит...
Возможно и напишу, если желание возникнет.
Однако для себя я проблему уже решил - просто стал пользоваться системами с более грамотно проработанными архитектурами.
Если вам непонятно в чем проблема, значт вас это действительно не касается.
| | |
| |
| 3.47, ander (??), 22:32, 14/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Мне надо, что бы это принципиально соответствовало принципам UNIX.
> Точнее чтобы была возможность привести в соответсвие с этими принципами для тех, кому это надо.
Просто вы бредите. В нормальных системах весь байкод компилируется раз - при установке. Все логично и UNIX way. И не лезьте туда. Если вы пишите програму - то финалаьная версия тоже должна компилиться в байкод только раз - при установке программы.
| | |
| |
| 4.48, langer (?), 19:27, 15/08/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Просто вы бредите. В нормальных системах весь байкод компилируется раз - при установке. Все логично и UNIX way. И не лезьте туда. Если вы пишите програму - то финалаьная версия тоже должна компилиться в байкод только раз - при установке программы.
А где вы увидели, что я предлагал, что-то компилировать после установки? И куда-то после установки "лезть".
Видимо это еще одна трактовка, что такое UNIX-way. В этой теме их уже прозвучало, если не ошибаюсь, как минимум две, не считая эту.
На этот раз оказывается, что UNIX-way по-вашему заключается исключительно в том, меняется что-то после установки или нет.
| | |
| |
| 5.49, ander (??), 02:04, 21/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> А где вы увидели, что я предлагал, что-то компилировать после установки?
> И куда-то после установки "лезть".
Вам не нравится где лежат байткоды, но это верное место, что я и пытался показать, тем более, как Вам уже и объяснили, байткод не сильно от исходников и отличается. Все логично и правильно.
> Видимо это еще одна трактовка, что такое UNIX-way. В этой теме их уже прозвучало, если
> не ошибаюсь, как минимум две, не считая эту.
> На этот раз оказывается, что UNIX-way по-вашему заключается исключительно в том,
> меняется что-то после установки или нет.
Похоже вы сами и не знаете, что такое "UNIX-way", поскольку так и не написали, какой из принципов нарушается.
P.S. Be simple :)
| | |
|
|
|
|
| |
| 2.44, Аноним (-), 02:24, 14/08/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Начнём с того, что когда я работал МНСом, учёные за 40 с удовольствием осваивали SVN и с радостью говорили "Во, такой-то штуки нам и не хватало!" Может, у вас что-то в консерватории не так?
Ну и сама мысль коллективно править исходники в одной общей помойке, как минимум, удивляет. Общая помойка - это безответственность и верная потеря данных в самый неподходящий момент. Но если оче хочется отстрелить себе ногу, то для вас ешё в XX веке придумали umask и setgid на каталоги, ну и POSIX ACL, это если хочется отстрелить ногу сразу по шею. Удачи.
И про run-time @INC customisation тоже непонятно. Вы мануал по Питону читали? Вот, http://docs.python.org/library/sys.html#sys.path и http://docs.python.org/using/cmdline.html#envvar-PYTHONPATH, прочтите, это бесплатно.
| | |
| |
| 3.45, langer (?), 05:06, 14/08/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
С правами доступа, конечно, товарищ загнул.
Описанные им проблемы нужно решать методом контроля версий, и никакие ACL даже не нужны (потому как мнутри систем контроля версий и так есть ACL).
Проблема с бинарниками Питона проще (но не меньше от этого).
В рантайм-каталогах лежит продублированный код, идентичный по функционалу и разный по формату. И все это только ради более быстрой загрузки с одинаковой скоростью работы.
Это не UNIX-way и вообще глупое решение.
Может это исправят в альтернативных реализациях?
| | |
| 3.46, Andrew Kolchoogin (?), 11:51, 14/08/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Я не буду вдаваться в дискуссии, где, кто и что с удовольствием осваивал.
А вот что касается прав доступа: ну-ка, расскажите-ка мне, каким образом я должен выставить umask и _любые_ биты в директории, чтобы более одного человека могли удалять такие-то и такие-то файлы, но не могли удалять другие? Перекомпиляция .pyc'шки -- это создание темпорарника и link()/unlink(), иначе пара копий Питона, попытающаяся перекомпилировать один и тот же модуль, накомпилирует чёрт-те что. Sticky не поможет, из очевидных соображений.
POSIX ACL? А что это? Или вы про драфт, который так и не стал стандартом, и пару лет назад заэкспайрился?
(Я даже не буду троллить на тему setgid на директории тупым вопросом "а что он делает" -- в BSD-системах setgid на директориях, как известно, игнорируется, а файлы _всегда_ создаются с той группой, которой директория принадлежит).
А про @INC и sys.path -- нет, не читал, поэтому честно и спросил в последнем предложении своего поста, умеет ли так же Питон.
А самое смешное -- что в современном Юниксе есть вполне себе разумное место для хранения кэшей -- ~/.cache. Раньше его не было, но и KDE, и GNOME умели кэшировать всё в /tmp/kdecache-${USER}/ и /tmp/orbit-${USER}/. То есть, проблему-то можно решить в корне и в UNIX-стиле.
| | |
|
|
|
