https://www.opennet.ru/openforum/vsluhforumID3/79663.html Представлен (http://wiki.cython.org/ReleaseNotes-0.15) релиз Cython 0.15 (http://cython.org/), варианта языка программирования Python, нацеленного на упрощение интеграции с кодом на языке Си. При помощи Cython создавать расширения на языке Си для основного Python-проекта так же просто, как писать на Python. Язык Cython максимально приближен к Python, но обладает возможностью прямого вызова функций на языке Си и поддерживает определение типов переменных как в языке Си. Подобный подход позволяет компилировать итоговый код на языке Cython в представление на языке Си, которое затем собирается штатным системным компилятором. <br><br><br><br>Производительность кода при использовании Cython примерно на 30% выше, чем при использовании CPython, в некоторых случаях, прирост скорости достигает 60-90%, например, при выполнении операций if-elif-else или при работе циклов. В настоящее время Cython не поддерживает (http://wiki.cython.org/Unsupported) некоторые конструкции языка Python. Тем не менее, конечной ...<br><br>URL: http://wiki.cy https://www.opennet.ru/openforum/vsluhforumID3/79663.html#49 Sat, 20 Aug 2011 22:04:19 GMT &gt; А где вы увидели, что я предлагал, что-то компилировать после установки? <br>&gt; И куда-то после установки "лезть".<br><br>Вам не нравится где лежат байткоды, но это верное место, что я и пытался показать, тем более, как Вам уже и объяснили, байткод не сильно от исходников и отличается. Все логично и правильно.<br><br>&gt; Видимо это еще одна трактовка, что такое UNIX-way. В этой теме их уже прозвучало, если<br>&gt; не ошибаюсь, как минимум две, не считая эту.<br>&gt; На этот раз оказывается, что UNIX-way по-вашему заключается исключительно в том,<br>&gt; меняется что-то после установки или нет.<br><br>Похоже вы сами и не знаете, что такое "UNIX-way", поскольку так и не написали, какой из принципов нарушается.<br><br>P.S. Be simple :)<br> https://www.opennet.ru/openforum/vsluhforumID3/79663.html#48 Mon, 15 Aug 2011 15:27:07 GMT &gt; Просто вы бредите. В нормальных системах весь байкод компилируется раз - при установке. Все логично и UNIX way. И не лезьте туда. Если вы пишите програму - то финалаьная версия тоже должна компилиться в байкод только раз - при установке программы.<br><br>А где вы увидели, что я предлагал, что-то компилировать после установки? И куда-то после установки "лезть".<br><br>Видимо это еще одна трактовка, что такое UNIX-way. В этой теме их уже прозвучало, если не ошибаюсь, как минимум две, не считая эту.<br>На этот раз оказывается, что UNIX-way по-вашему заключается исключительно в том, меняется что-то после установки или нет.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/79663.html#47 Sun, 14 Aug 2011 18:32:17 GMT &gt; Мне надо, что бы это принципиально соответствовало принципам UNIX.<br>&gt; Точнее чтобы была возможность привести в соответсвие с этими принципами для тех, кому это надо.<br><br>Просто вы бредите. В нормальных системах весь байкод компилируется раз - при установке. Все логично и UNIX way. И не лезьте туда. Если вы пишите програму - то финалаьная версия тоже должна компилиться в байкод только раз - при установке программы.<br> https://www.opennet.ru/openforum/vsluhforumID3/79663.html#46 Sun, 14 Aug 2011 07:51:47 GMT Я не буду вдаваться в дискуссии, где, кто и что с удовольствием осваивал.<br><br>А вот что касается прав доступа: ну-ка, расскажите-ка мне, каким образом я должен выставить umask и _любые_ биты в директории, чтобы более одного человека могли удалять такие-то и такие-то файлы, но не могли удалять другие? Перекомпиляция .pyc'шки -- это создание темпорарника и link()/unlink(), иначе пара копий Питона, попытающаяся перекомпилировать один и тот же модуль, накомпилирует чёрт-те что. Sticky не поможет, из очевидных соображений.<br><br>POSIX ACL? А что это? Или вы про драфт, который так и не стал стандартом, и пару лет назад заэкспайрился?<br><br>(Я даже не буду троллить на тему setgid на директории тупым вопросом "а что он делает" -- в BSD-системах setgid на директориях, как известно, игнорируется, а файлы _всегда_ создаются с той группой, которой директория принадлежит).<br><br>А про @INC и sys.path -- нет, не читал, поэтому честно и спросил в последнем предложении своего поста, умеет ли так же Питон.<br><br>А самое смешное -- что в с https://www.opennet.ru/openforum/vsluhforumID3/79663.html#45 Sun, 14 Aug 2011 01:06:38 GMT С правами доступа, конечно, товарищ загнул.<br>Описанные им проблемы нужно решать методом контроля версий, и никакие ACL даже не нужны (потому как мнутри систем контроля версий и так есть ACL).<br><br>Проблема с бинарниками Питона проще (но не меньше от этого).<br>В рантайм-каталогах лежит продублированный код, идентичный по функционалу и разный по формату. И все это только ради более быстрой загрузки с одинаковой скоростью работы.<br><br>Это не UNIX-way и вообще глупое решение.<br>Может это исправят в альтернативных реализациях?<br> https://www.opennet.ru/openforum/vsluhforumID3/79663.html#44 Sat, 13 Aug 2011 22:24:04 GMT Начнём с того, что когда я работал МНСом, учёные за 40 с удовольствием осваивали SVN и с радостью говорили "Во, такой-то штуки нам и не хватало!" Может, у вас что-то в консерватории не так?<br><br>Ну и сама мысль коллективно править исходники в одной общей помойке, как минимум, удивляет. Общая помойка - это безответственность и верная потеря данных в самый неподходящий момент. Но если оче хочется отстрелить себе ногу, то для вас ешё в XX веке придумали umask и setgid на каталоги, ну и POSIX ACL, это если хочется отстрелить ногу сразу по шею. Удачи.<br><br>И про run-time @INC customisation тоже непонятно. Вы мануал по Питону читали? Вот, http://docs.python.org/library/sys.html#sys.path и http://docs.python.org/using/cmdline.html#envvar-PYTHONPATH, прочтите, это бесплатно.<br> https://www.opennet.ru/openforum/vsluhforumID3/79663.html#43 Sat, 13 Aug 2011 21:45:07 GMT Тут прозвучала где-то верная мысль, что хранение Питоновского байткода рядом с скриптом модуля -- это подход либо виндозника, либо "админа локалхоста".<br><br>Просто на реальной многопользовательской системе в этом случае пользоваться скомпилированным байткодом _в некоторых случаях_ становится просто невозможно, и вот почему.<br><br>Представьте себе группу программистов, работающих над проектом на Питоне. Причём не над проектом "для сдачи заказчику", а над проектом "для себя", к примеру, это учёные, которые пишут софтину для обработки относительно своих математических моделей данных, получаемых с ЯМР-спектрометра фирмы "Хренов и Огурцов".<br>Стоит в лаборатории числодробилка, на которой нежными руками сисадмина собран numpy, слинкованный с Атласом -- вся математика будет обрабатываться с охрененной скоростью оптимизированного кода на Фортране, а интерфейс может и потормозить, зато среднему учёному изучить скриптовый Питон куда проще, чем тот же самый Фортран или C. Также среднему учёному наплевать на всякие там SCM'ы и https://www.opennet.ru/openforum/vsluhforumID3/79663.html#41 Sat, 13 Aug 2011 03:00:32 GMT Во-первых, вы ничего не поняли. Они не мешают, они лежат не на своем месте.<br>Причем, не столько *.pyc, сколько *.py при наличии *.pyc.<br><br>&gt; Если *.pyc уж так уж мешают, то можно сделать export PYTHONDONTWRITEBYTECODE=yes<br><br>Да, на текущий момент, это решение. Только не во всех пакетных дистрибутивах опять-таки от *.pyc легко избавиться.<br><br>Правда я уже говорил, я на данный момент нашел для себя решение еще лучше.<br>Стараться не использовать Питон, и убирать его ото всюду, откуда можно.<br><br>&gt; А ещё можно удалить *.py и оставить только скомпилированный байткод.<br><br>А это будет работать со всеми библиотеками/фреймворками?<br>Вы проверяли? Это поддерживается?<br><br>&gt; Только не понятно зачем: какая разница, что лежит в lib/python/site-packages/* ?<br><br>Вы забыли еще про lib/python/*<br><br>Если вам не понятно и нет разницы, то это действительно вас не должно волновать.<br>Так же как вам, судя по всему, не будет разницы, если в каких-то реализациях Питона это будет сделано по-другому.<br><br>И вообще, как было сказано в начале поста, вы https://www.opennet.ru/openforum/vsluhforumID3/79663.html#40 Fri, 12 Aug 2011 22:40:24 GMT Если *.pyc уж так уж мешают, то можно сделать export PYTHONDONTWRITEBYTECODE=yes<br><br>А ещё можно удалить *.py и оставить только скомпилированный байткод.<br><br>Только не понятно зачем: какая разница, что лежит в lib/python/site-packages/* ?<br>