The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз Cython 0.15, варианта языка Python, поддерживающего плотную интеграцию с Си

11.08.2011 20:46

Представлен релиз Cython 0.15, варианта языка программирования Python, нацеленного на упрощение интеграции с кодом на языке Си. При помощи Cython создавать расширения на языке Си для основного Python-проекта так же просто, как писать на Python. Язык Cython максимально приближен к Python, но обладает возможностью прямого вызова функций на языке Си и поддерживает определение типов переменных как в языке Си. Подобный подход позволяет компилировать итоговый код на языке Cython в представление на языке Си, которое затем собирается штатным системным компилятором.

Производительность кода при использовании Cython примерно на 30% выше, чем при использовании CPython, в некоторых случаях, прирост скорости достигает 60-90%, например, при выполнении операций if-elif-else или при работе циклов. В настоящее время Cython не поддерживает некоторые конструкции языка Python. Тем не менее, конечной целью проекта, является намерение предоставить возможность выполнения обычных скриптов на языке Python и обеспечить поддержку прохождения стандартного тестового комплекта Python.

В новой версии обеспечена поддержка генераторов, добавлено ключевое слово nonlocal, обеспечена поддержка OpenMP, представлена более быстрая реализация выражения "with", реализованы PEP-3134 (Exception Chaining) и PEP-382 (относительный импорт).

  1. Главная ссылка к новости (http://wiki.cython.org/Release...)
  2. Cython FAQ
Автор новости: vitja
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31452-Cython
Ключевые слова: Cython, python, compile, gcc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (46) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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.9, all_glory_to_the_hypnotoad (ok), 10:08, 12/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    и конечно же, выше подразумеваю cpython
     
  • 3.10, langer (?), 11:42, 12/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Собственно, от байткода в питоне по сути только название, фактически это те же самые исходники в бинарном виде.

    Тем более.

     
     
  • 4.12, all_glory_to_the_hypnotoad (ok), 11:48, 12/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    что тем более? бинарник грузится в разы быстрее
     
     
  • 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.27, all_glory_to_the_hypnotoad (ok), 22:21, 12/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    в спитоне так вышло исключительно по историческим соображениям
     
  • 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 +/
    Ну то есть он по-вашему никак не компилируемый Я уже понял вашу точку зрения К... текст свёрнут, показать
     
     
  • 10.34, anonym (?), 23:47, 12/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Столько много красивых фраз с умным видом, при это знаком с предметом едва ... текст свёрнут, показать
     
     
  • 11.35, langer (?), 00:09, 13/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Где вы здесь видите словосочетание программа без байткода it is read from a ... текст свёрнут, показать
     
     
  • 12.36, anonym (?), 00:27, 13/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    зачем столько много слов создай текстовый файл hello, помести в него следующее ... текст свёрнут, показать
     
     
  • 13.37, langer (?), 00:49, 13/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну почему же Мне моего внимания не жалко А как вы определили, что никаких бай... текст свёрнут, показать
     
     
  • 14.38, anonym (?), 01:01, 13/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Только потому, что не появился файл с байткодом Не нравилась только его прагмат... текст свёрнут, показать
     
     
  • 15.39, langer (?), 01:11, 13/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да Именно так я и сказал И что Вы решили просто мне подражать и привести м... текст свёрнут, показать
     
  • 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 +/
    Услышим ли мы ваше мнение, а не разоблачение ваших фантазий, приписываемых другим?
     
     
  • 7.32, langer (?), 23:23, 12/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Услышим ли мы ваше мнение,

    Я уже сказал свое мнение в самом начале.
    Вот здесь: http://www.opennet.ru/openforum/vsluhforumID3/79663.html#4

    Что вы еще от меня хотите?

    > а не разоблачение ваших фантазий, приписываемых другим?

    Что именно я вам приписал по-вашему, чего вы сами не говорили?

     
  • 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 :)

     

  • 1.43, Andrew Kolchoogin (?), 01:45, 14/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Тут прозвучала где-то верная мысль, что хранение Питоновского байткода рядом с с... большой текст свёрнут, показать
     
     
  • 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-стиле.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру