Представлен (http://wiki.cython.org/ReleaseNotes-0.15) релиз Cython 0.15 (http://cython.org/), варианта языка программирования Python, нацеленного на упрощение интеграции с кодом на языке Си. При помощи Cython создавать расширения на языке Си для основного Python-проекта так же просто, как писать на Python. Язык Cython максимально приближен к Python, но обладает возможностью прямого вызова функций на языке Си и поддерживает определение типов переменных как в языке Си. Подобный подход позволяет компилировать итоговый код на языке Cython в представление на языке Си, которое затем собирается штатным системным компилятором.Производительность кода при использовании Cython примерно на 30% выше, чем при использовании CPython, в некоторых случаях, прирост скорости достигает 60-90%, например, при выполнении операций if-elif-else или при работе циклов. В настоящее время Cython не поддерживает (http://wiki.cython.org/Unsupported) некоторые конструкции языка Python. Тем не менее, конечной ...
URL: http://wiki.cython.org/ReleaseNotes-0.15
Новость: https://www.opennet.ru/opennews/art.shtml?num=31452
А если использовать указания типов, то можно повысить производительность в разы, правда тогда от синтаксиса python остаётся не так уж и много, но всё равно расширения гораздо проще чем на pure-C писать.
Без генераторов и некоторых других вкусных питонизмов это всё было совсем не интересно.
ой, да бросьте вы, когда действительно важна скорость и на голом асме писать будешь, вопрос только в том, под какой проц писать этот самый код на асме?!
Последний раз пробовал версию 0.11. Писать в привычном питоновском стиле оказалось невозможно, то то не поддерживалось, то это. В результате гипотетическое ускорение оказалось не стоящим ясности и краткости кода, да и обычный Питон как раз теми средствами, что отсутствовали в Cython, хорошо поднимал производительность. Если догнали Питон по фичам — хорошо, нужно будет ещё посмотреть. Но что-то разработчики CPython не проявили энтузиазма на недавнее предложение писать оптимизированные версии стандартных модулей на Cython. Не воспринимают его пока всерьёз.
Мне в Питоне многое нравилось.
Не нравилась только его прагматика. - Держать скомпилированный байткод рядом с исходниками. Это не UNIX-way. Именно поэтому я его и бросил.Или уж только исходники. Как в Ruby или JS.
Или бинарники должны лежать отдельно.
Например, как это сделано в Erlang.
Или в той же java. Только в java другая болезнь - каждый проект тащит свой набор библиотек. Ну да с ней все понятно - она полувиндовая была сразу.Но что мешало в Питоне это сразу сделать грамотно?
Хотя по идее это только вопрос перепаковки дистрибутива и небольших патчей на ядро, чтобы он брал бинарники из отдельных путей.Надеюсь, что кто-нибуть такой проект сделает. Или может это уже в других реализациях есть.
> Или уж только исходники. Как в Ruby или JS.В Руби тоже есть байткод, и он тоже лежит рядом с исходниками, только эта фича выключена по умолчанию.
> В Руби тоже есть байткод, и он тоже лежит рядом с исходниками, только эта фича выключена по умолчанию.Ну видимо кто-то из девелоперов Руби пытается эту дурную традацию лоббировать.
Благо что здравый смысл пока побеждает.Если уж решили делать отдельный байт-код, то нужно его держать отдельно от исходников.
А не идти на поводу у виндузятников в UNIX-системах.Тем более, что сделать нормальную организацию файлов гораздо легче, чем реализовать сам байт-код.
в 3ей версии он кладёт байткод в отдельную поддиректорию, но всё равно вместе с исходниками. Собственно, от байткода в питоне по сути только название, фактически это те же самые исходники в бинарном виде.
и конечно же, выше подразумеваю cpython
> Собственно, от байткода в питоне по сути только название, фактически это те же самые исходники в бинарном виде.Тем более.
что тем более? бинарник грузится в разы быстрее
> что тем более? бинарник грузится в разы быстрееКакую часть по-вашему составляет суммарное время загрузки питоновского кода от суммарного времени работы приложений на питоне?
Тем более, что каждый модуль грузится только один раз. (Если не был сделан принудительный reload, что встречается крайне редко в основной массе кода.)И все это безобразие в файловой системе только ради того, чтобы модули грузились быстрее.
> Какую часть по-вашему составляет суммарное время загрузки питоновского кода от суммарного времени работы приложений на питоне?это зависит от приложения, где-то может составлять значительную часть. Так же не стоит забывать, что даже простое приложение может грузить сотни файлов с кодом из библиотек.
>> Какую часть по-вашему составляет суммарное время загрузки питоновского кода от суммарного времени работы приложений на питоне?
> это зависит от приложения, где-то может составлять значительную часть. Так же не стоит забывать, что даже простое приложение может грузить сотни файлов с кодом из библиотек.Если программа грузит сотни файлов кода, то обычно рассчитывается, что и работает она достаточно долго.
Если программа грузится однократно, то это тоже не проблема, какое бы она время не работала.Если же по каким-то идиотским причинам программа на Питоне перезагружается в цикле из шелл-скрипта со всеми своими библиотеками и работает меньше, чем грузится, тогда обычно пишут загрузчик на самом Питоне в пару строк, который в цикле вызывает остальной код.
Модули-то загружаются однократно. Эта фича ведь в Питоне существует.
В-общем, нет никаких оправданий для этого маразма с дублированием одного кода в разных форматах.
А если уж решили делать отдельно файлы с байт-кодом, то нужно было их раскладывать, как это положено в UNIX. Методика эта проверенная, и ничего изобретать тут не было нужно.
Насколько я понимаю, в Питоне байткод создаётся для импортируемых модулей, чтобы быстро импортировалось. Байткод одинаков для Linux/Windows/MacOS. Зачем его хранить по "Unix-way"?
> Насколько я понимаю, в Питоне байткод создаётся для импортируемых модулей, чтобы быстро
> импортировалось. Байткод одинаков для Linux/Windows/MacOS. Зачем его хранить по "Unix-way"?Ответ нахотится в вашем вопросе. "Linux/Windows/MacOS" - два против одного.
Или вы не видели систем, сделанных в соответсвии с UNIX-way, которые при этом были портированы в Винды.
Тем более, что виндоводам обычно по барабану где что лежит, так что их интересы при этом никак не пострадают.
ты просто путаешь разные подходы для разных языков. Питон - скриптовый язык он работает из текстового файла. Байткод создается автоматически для некоторого ускорения работы, не является скомпилированным файлом как в C/C++. Тут нету понятия исходный код и бинарники. нету никакого смыла ему лежать где либо ещё.Засрал всю тему своей идиотической претензией.
> ты просто путаешь разные подходы для разных языков.То что у него именно другой "подход" - я это прекрасно понимаю.
> Питон - скриптовый язык он работает из текстового файла.
То есть вы считаете, что скриптовые языки - это такие, которые "работают из текстовых файлов". Именно так вы понимаете отличительную особенность скриптовых языков.
И "подход", используемый Питоном, - это по-вашему не "подход" самого Питона (точнее его создателей), а "подход" абсолютно всех скриптовых языков.Только вот незадача. Если модуль загружен из файла с байт-кодом, то как же он тогда "работает из текстового файла".
> Байткод создается автоматически для некоторого ускорения работы,
Ну да, и в случае с Питоном байт-код "автоматически" лежит в системных каталогах с правами только на чтение.
Видимо вы привыкли б..кодить с правами рута на все. Или вообще из-под Виндов Питон юзаете.> не является скомпилированным файлом как в C/C++.
Значит вы считаете, что если не происходит компиляции в машинный код, то по-вашему вообще не происходит никакой компиляции, и файл с байт-кодом по-вашему не является скомпилированным файлом.
И видимо вы уверены, что в языках, где нет файлов с байт-кодом, там по-вашему вообще байт-кода нет, как и компиляции.
> Тут нету понятия исходный код и бинарники.
Значит для вас файлы с байт-кодом Питона бинарниками не являются.
> нету никакого смыла ему лежать где либо ещё.
В вашем понимании смысла - это действительно так.
> Засрал всю тему своей идиотической претензией.
Это неудивительно, что с вашим пониманием отличительной особенности скриптовых языков, как "работы из текстовых файлов" - подобные претензии вам кажутся "идиотическими".
--------------------------
По крайней мере можно сделать вывод, в угоду какой аудитории основная реализация Питона разрабатывается.
Остается надежда, что может быть в альтернативных реализациях не будут так гнаться за ширпотребностью.
Благо, что на Питоне свет клином не сошелся.
в спитоне так вышло исключительно по историческим соображениям
>Только вот незадача. Если модуль загружен из файла с байт-кодом, то как же он тогда "работает из текстового файла".http://docs.python.org/tutorial/modules.html
байткод создается автоматом при импорте модуля, при этом используется время модификации текстового файла (.py), если оно не совпадает с байткодом (.pyc), то последний будет проигнорирован.
Питон - интерпретируемый язык. В этом его преимущество и недостаток. Программу на Питоне не нужно компилить. С байткодом программа не работает быстрее, но считывается байткод быстрее чем текстовый.
>>Только вот незадача. Если модуль загружен из файла с байт-кодом, то как же он тогда "работает из текстового файла".
> http://docs.python.org/tutorial/modules.html
>
> байткод создается автоматом при импорте модуля, при этом используется время модификации текстового файла (.py), если оно не совпадает с байткодом (.pyc), то последний будет проигнорирован.Я знаю, как импортируются модули в Питоне.
Ну и? А если ".pyc" не будет проигнорирован? Как модуль будет по-вашему "работать из текстового файла". Видимо ваше сознание просто не способно обработать обе ветки конструкции "если-то-иначе".Ах, ну да, в приведенной вами цитате альтернатива была опущена. И вы радостно решили, что видимо байт-код будет игнорироваться всегда. А зачем он тогда нужен? А вот! В конце вы даете свою трактовку, зачем по-вашему.
Похоже вы только сейчас начали лихорадочно читать документацию, да и то понять не можете, что там написано.
До этого вы заявили буквально следующее: "Питон - скриптовый язык он работает из текстового файла". Продемонстрировав, как вы понимаете, что такое скриптовые языки.
> Питон - интерпретируемый язык. В этом его преимущество и недостаток.
Еще лучше. Теперь оказывается Питон в вашем понимании внезапно перестал быть скриптовым и стал интерпретируемым.
> Программу на Питоне не нужно компилить.
Ну я понял уже, что вы убеждены, что при создании байт-кода никакой компиляции не происходит.
> С байткодом программа не работает быстрее, но считывается байткод быстрее чем текстовый.
Вообще замечательно. Оказывается с байткодом программа по-вашему не работает быстрее, а просто быстрее считывается. Ухаха.
Вот я и говорю. К сожалению видимо главная реализация Питона рассчитана именно на такую аудиторию. Может быть другие реализации будут учитывать интересы в первую очередь профессиональных разработчиков.
Ну а какой тут конфликт в том что он скриптовый и интерпретируемый?
Видишь ли, бинарный файл считывается интерпретатором быстрее чем текстовый, но сама работа программ при этом одинаковая. В бинарном файле те же инструкции что и в текстовом. Так написано в docs.python.org. Но ты можешь продолжать смеяться. Думаю местную аудиторию ты тоже позабавил.
> Ну а какой тут конфликт в том что он скриптовый и интерпретируемый?Ну то есть он по-вашему никак не компилируемый. Я уже понял вашу точку зрения.
Кроме того, вы заявили так: "Питон - скриптовый язык он работает из текстового файла."
> Видишь ли, бинарный файл считывается интерпретатором быстрее чем текстовый, но сама работа программ при этом одинаковая.
Ну я понял уже, что вы именно так думаете. Это вы уже говорили.
> В бинарном файле те же инструкции что и в текстовом.
Пацталом.
> Так написано в docs.python.org.
Это где там так написано?
> Но ты можешь продолжать смеяться.
Я и продолжаю.
> Думаю местную аудиторию ты тоже позабавил.
Думайте как вам угодно.
>A program doesn’t run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that’s faster about .pyc or .pyo files is the speed with which they are loaded.
>langerСтолько много красивых фраз с умным видом, при это знаком с предметом едва.
>>A program doesn’t run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that’s faster about .pyc or .pyo files is the speed with which they are loaded.
>
> Столько много красивых фраз с умным видом, при это знаком с предметом едва.Где вы здесь видите словосочетание "программа без байткода"?
"it is read from a .py file" - это что ли по-вашему "программа без байткода"?Вы сначала по-английски читать научитесь.
Что вы называете "программой без байт-кода"? "Без байт-кода" - это когда байт-кода нет вообще. А не то, откуда именно он получается.
А теперь еще раз все ваши высказывания.
> Питон - скриптовый язык он работает из текстового файла.
> Байткод создается автоматически для некоторого ускорения работы, не является скомпилированным файлом как в C/C++.
> Программу на Питоне не нужно компилить.
> В бинарном файле те же инструкции что и в текстовом.Где это сказано в документации?
> Тут нету понятия исходный код и бинарники.
Понятия может у вас и нет, а бинарники есть.
И контрольный вопрос в голову.
Зачем все-таки по-вашему нужен байт-код? Чтобы программа просто быстрее грузилась?
зачем столько много слов?создай текстовый файл hello, помести в него следующее:
print 'Hello I am Dartanian'запусти из консоли
python helloзамени на:
print 'Hello Opennet'запусти из консоли
python helloзаметь что при этом никаких байткодов не было создано вообще, а программа работает...
Предполагается что версия Питона 2.*. Я понимаю что пример слишком прост и не достоин твоего внимания, но как мне ещё объяснить очевидные вещи.
> запусти из консоли
> python hello
> заметь что при этом никаких байткодов не было создано вообще, а программа работает...
> Предполагается что версия Питона 2.*. Я понимаю что пример слишком прост и не достоин твоего внимания, но как мне ещё объяснить очевидные вещи.Ну почему же. Мне моего внимания не жалко.
А как вы определили, что "никаких байткодов не было создано вообще"?
Только потому, что не появился файл с байткодом?> Питон - скриптовый язык он работает из текстового файла.
Ну да, при таком вашем понимании скриптовых языков байткод - это видимо по-вашему такая фишка, которая просто помогает запускать программу. А саму работающую программу вы называете "программой без байт-кода".
При этом, как именно она работает, что там именно происходит - это уже выше вашего понимания.
"а программа работает..." - решающий убийственный аргумент всех быдлокодеров.> В бинарном файле те же инструкции что и в текстовом.
С вашими представлениями о байткоде все ясно.
Теперь было бы еще очень интересно узнать, что же такое в вашем понимании "инструкция".
>А как вы определили, что "никаких байткодов не было создано вообще"?Только потому, что не появился файл с байткодом?
>Мне в Питоне многое нравилось.
Не нравилась только его прагматика. - Держать скомпилированный байткод рядом с исходниками. Это не UNIX-way. Именно поэтому я его и бросил.
>>А как вы определили, что "никаких байткодов не было создано вообще"?
>>Только потому, что не появился файл с байткодом?
>>
>>Мне в Питоне многое нравилось.
>>Не нравилась только его прагматика. - Держать скомпилированный байткод рядом с исходниками.
>>Это не UNIX-way. Именно поэтому я его и бросил.Ну да. Именно так я и сказал. И что?
Вы решили просто мне подражать и привести мои цитаты так же, как я привел ваши.Но теперь вы не можете понять, почему при перечитывании собственных слов вы чувствуете себя глупо, а я - нет.
Что текстовые исходники, что бинарный байткод — всё это архитектурно-независимые ресурсы, с точки зрения Unix разницы между ними практически нет. Ну да, можно байткод хранить в /var/cache (если есть исходники, он всё равно генерируется при инсталляции), только зачем? Что он генерируется? Ну так часть ресурсов тоже генерируется, например ядерные модули-посредники для проприетарных драйверов, шрифты, каталоги, символические ссылки.
> Что текстовые исходники, что бинарный байткод — всё это архитектурно-независимые ресурсы, с точки зрения Unix разницы между ними практически нет. Ну да, можно байткод хранить в /var/cache (если есть исходники, он всё равно генерируется при инсталляции), только зачем? Что он генерируется? Ну так часть ресурсов тоже генерируется, например ядерные модули-посредники для проприетарных драйверов, шрифты, каталоги, символические ссылки.То есть вы считаете, что хранить байт-код в /var/cache - это и есть UNIX-way.
"с точки зрения Unix" есть еще организация файловой системы. Просто вы об этом мало что знаете.
Подавляющее количество байт-кода Питона не генерируется в runtime. Но вы почему-то решили, что дело именно в этом. Ту малую часть, что генерируется можно действительно положить в var, но только не в /var/cache, потому что это не кеш.
Хотя, действительно, питоновский байт-код ведет себя скорее как кеш. Что и сбивает с толку тех, кто начали изучение программирования с Питона.
Спасибо, что просвещаете воображаемый образ собеседника. Буду рад узнать и о других приписываемых мне вами заблуждениях.Если вы что-то слышали о FHS, может быть объясните, в чём с его (как вы это понимаете) точки зрения отличаются текстовые исходники и бинарный байткод установленных модулей и скриптов Питона и где им место?
>Спасибо, что просвещаете воображаемый образ собеседника. Буду рад узнать и о других приписываемых мне вами заблуждениях.
>
> Если вы что-то слышали о FHS, может быть объясните, в чём с его (как вы это понимаете) точки зрения отличаются текстовые исходники и бинарный байткод установленных модулей и скриптов Питона и где им место?То есть вы "что-то слышали о FHS", но при этом считаете, что с этой точки между исходниками и байт-кодом разницы нет. Также вы считаете, что с точки зрения FHS лучшее место для байт-кода - это по-вашему /var/cache.
Подсказка 1. Посмотрите как это сделано в языках, которые имеют качественную поддержку байт-кода, и при этом соответствуют идеологии UNIX.
Подсказка 2. Не ищите ответ там, где ищут "миллионы мух".
Услышим ли мы ваше мнение, а не разоблачение ваших фантазий, приписываемых другим?
> Услышим ли мы ваше мнение,Я уже сказал свое мнение в самом начале.
Вот здесь: https://www.opennet.ru/openforum/vsluhforumID3/79663.html#4Что вы еще от меня хотите?
> а не разоблачение ваших фантазий, приписываемых другим?
Что именно я вам приписал по-вашему, чего вы сами не говорили?
Если *.pyc уж так уж мешают, то можно сделать export PYTHONDONTWRITEBYTECODE=yesА ещё можно удалить *.py и оставить только скомпилированный байткод.
Только не понятно зачем: какая разница, что лежит в lib/python/site-packages/* ?
Во-первых, вы ничего не поняли. Они не мешают, они лежат не на своем месте.
Причем, не столько *.pyc, сколько *.py при наличии *.pyc.> Если *.pyc уж так уж мешают, то можно сделать export PYTHONDONTWRITEBYTECODE=yes
Да, на текущий момент, это решение. Только не во всех пакетных дистрибутивах опять-таки от *.pyc легко избавиться.
Правда я уже говорил, я на данный момент нашел для себя решение еще лучше.
Стараться не использовать Питон, и убирать его ото всюду, откуда можно.> А ещё можно удалить *.py и оставить только скомпилированный байткод.
А это будет работать со всеми библиотеками/фреймворками?
Вы проверяли? Это поддерживается?> Только не понятно зачем: какая разница, что лежит в lib/python/site-packages/* ?
Вы забыли еще про lib/python/*
Если вам не понятно и нет разницы, то это действительно вас не должно волновать.
Так же как вам, судя по всему, не будет разницы, если в каких-то реализациях Питона это будет сделано по-другому.И вообще, как было сказано в начале поста, вы не правильно поняли суть вопроса.
А если вам нет разницы, и вы не понимаете проблему, зачем давать пустые советы?
Чтобы казаться умнее?
Решительно бред. Удали исходники, оставь байткод. Не пойму в чем проблема даже. Или тебе надо чтобы принципиально байткод лежал в другом каталоге? На Земле сотни тысяч программистов, ну вот это одна из фантазий одного из них... Напиши GvR о ней...
Проблема есть, она в том, что байткод крайне сложно защитить от реверс-инжениринга, а не в том где что лежит...
> Решительно бред. Удали исходники, оставь байткод.Это решение поддерживаемое?
> Или тебе надо чтобы принципиально байткод лежал в другом каталоге?
Мне надо, что бы это принципиально соответствовало принципам UNIX.
Точнее чтобы была возможность привести в соответсвие с этими принципами для тех, кому это надо.> Не пойму в чем проблема даже.
> На Земле сотни тысяч программистов, ну вот это одна из фантазий одного из них... Напиши GvR о ней...
> Проблема есть, она в том, что байткод крайне сложно защитить от реверс-инжениринга, а не в том где что лежит...Возможно и напишу, если желание возникнет.
Однако для себя я проблему уже решил - просто стал пользоваться системами с более грамотно проработанными архитектурами.Если вам непонятно в чем проблема, значт вас это действительно не касается.
> Мне надо, что бы это принципиально соответствовало принципам UNIX.
> Точнее чтобы была возможность привести в соответсвие с этими принципами для тех, кому это надо.Просто вы бредите. В нормальных системах весь байкод компилируется раз - при установке. Все логично и UNIX way. И не лезьте туда. Если вы пишите програму - то финалаьная версия тоже должна компилиться в байкод только раз - при установке программы.
> Просто вы бредите. В нормальных системах весь байкод компилируется раз - при установке. Все логично и UNIX way. И не лезьте туда. Если вы пишите програму - то финалаьная версия тоже должна компилиться в байкод только раз - при установке программы.А где вы увидели, что я предлагал, что-то компилировать после установки? И куда-то после установки "лезть".
Видимо это еще одна трактовка, что такое UNIX-way. В этой теме их уже прозвучало, если не ошибаюсь, как минимум две, не считая эту.
На этот раз оказывается, что UNIX-way по-вашему заключается исключительно в том, меняется что-то после установки или нет.
> А где вы увидели, что я предлагал, что-то компилировать после установки?
> И куда-то после установки "лезть".Вам не нравится где лежат байткоды, но это верное место, что я и пытался показать, тем более, как Вам уже и объяснили, байткод не сильно от исходников и отличается. Все логично и правильно.
> Видимо это еще одна трактовка, что такое UNIX-way. В этой теме их уже прозвучало, если
> не ошибаюсь, как минимум две, не считая эту.
> На этот раз оказывается, что UNIX-way по-вашему заключается исключительно в том,
> меняется что-то после установки или нет.Похоже вы сами и не знаете, что такое "UNIX-way", поскольку так и не написали, какой из принципов нарушается.
P.S. Be simple :)
Тут прозвучала где-то верная мысль, что хранение Питоновского байткода рядом с скриптом модуля -- это подход либо виндозника, либо "админа локалхоста".Просто на реальной многопользовательской системе в этом случае пользоваться скомпилированным байткодом _в некоторых случаях_ становится просто невозможно, и вот почему.
Представьте себе группу программистов, работающих над проектом на Питоне. Причём не над проектом "для сдачи заказчику", а над проектом "для себя", к примеру, это учёные, которые пишут софтину для обработки относительно своих математических моделей данных, получаемых с ЯМР-спектрометра фирмы "Хренов и Огурцов".
Стоит в лаборатории числодробилка, на которой нежными руками сисадмина собран numpy, слинкованный с Атласом -- вся математика будет обрабатываться с охрененной скоростью оптимизированного кода на Фортране, а интерфейс может и потормозить, зато среднему учёному изучить скриптовый Питон куда проще, чем тот же самый Фортран или C. Также среднему учёному наплевать на всякие там SCM'ы и проч.: он логинится в Юникс и своим любимым текстовым редактором правит свой любимый исходник на Питоне.Разумеется, что лежит это всё в ${PREFIX}/lib/python${PYTHON_VER}/site_packages, где ему и положено, ибо где ему ещё лежать -- над проектом работают несколько человек, один пишет "разгребатор" данных, приходящих с ЯМР-гроба, другой -- математику, третий -- интерфейс.
А теперь, внимание, вопрос: какие права должна иметь директория site_packages, и кому она должна принадлежать, чтобы Питон смог прекомпилировать все модули, которые пишутся этими тремя людьми? И при этом сам системный администратор вдруг случайно не обнаружил, что из-за того, что математик, задумавшись, не сказал 'rm -R' не в той директории, ни одного из стапицоттыщ Питоновских модулей, установленных в системе, больше нет?
Если в моём рассуждении заменить слово "Питон" на слова "Перл версии 5.12 или старше", то ситуация становится вполне понятной: весь код должен лежать в групповой директории, доступной этим троим на запись, а вначале главного файла нужно в '@INC' запихнуть путь к ней -- Перл поддерживает run-time @INC customisation, если его правильно собрать.
Но Питон, насколько мне известно, не поддерживает. Как быть?
Начнём с того, что когда я работал МНСом, учёные за 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, прочтите, это бесплатно.
С правами доступа, конечно, товарищ загнул.
Описанные им проблемы нужно решать методом контроля версий, и никакие ACL даже не нужны (потому как мнутри систем контроля версий и так есть ACL).Проблема с бинарниками Питона проще (но не меньше от этого).
В рантайм-каталогах лежит продублированный код, идентичный по функционалу и разный по формату. И все это только ради более быстрой загрузки с одинаковой скоростью работы.Это не UNIX-way и вообще глупое решение.
Может это исправят в альтернативных реализациях?
Я не буду вдаваться в дискуссии, где, кто и что с удовольствием осваивал.А вот что касается прав доступа: ну-ка, расскажите-ка мне, каким образом я должен выставить umask и _любые_ биты в директории, чтобы более одного человека могли удалять такие-то и такие-то файлы, но не могли удалять другие? Перекомпиляция .pyc'шки -- это создание темпорарника и link()/unlink(), иначе пара копий Питона, попытающаяся перекомпилировать один и тот же модуль, накомпилирует чёрт-те что. Sticky не поможет, из очевидных соображений.
POSIX ACL? А что это? Или вы про драфт, который так и не стал стандартом, и пару лет назад заэкспайрился?
(Я даже не буду троллить на тему setgid на директории тупым вопросом "а что он делает" -- в BSD-системах setgid на директориях, как известно, игнорируется, а файлы _всегда_ создаются с той группой, которой директория принадлежит).
А про @INC и sys.path -- нет, не читал, поэтому честно и спросил в последнем предложении своего поста, умеет ли так же Питон.
А самое смешное -- что в современном Юниксе есть вполне себе разумное место для хранения кэшей -- ~/.cache. Раньше его не было, но и KDE, и GNOME умели кэшировать всё в /tmp/kdecache-${USER}/ и /tmp/orbit-${USER}/. То есть, проблему-то можно решить в корне и в UNIX-стиле.