Python-сообщество

если файлы будут скрыты, то это не значит что они перестанут существовать

предусмотрели добавление <magic> для использования разных версий питона
почему нельзя было предусмотреть изменение пути и подобное “кодирование” для пути в фс

это ведь лучше, чем тратить постоянно производительность на попытки создания файлов .pyc в ro фс (или при ограничении прав на запись)

Можно отключить отображение файлов в IDE и даже в некоторых редакторах (если IDE не нравится).
На деплой они вообще не влияют.
На систему контроля версий - тоже.

мне не надо отключать отображение файлов в ide, файловой системе или еще где
мне даже не надо отключать их создание (т.к. это костыль и влияет на производительность)
мне надо хранить .pyc в определенном каталоге, а не размазанными по всему дереву файловой системы

можно еще конечно подправить модуль импорта питона
но это тоже костыль, т.к. не пойдет в апстрим

Отредактировано web_pr (Сен. 25, 2013 01:02:37)

malya
Просто раздражает куча этих файлов в рабочей директории,

:) мне кажется надо уточнить постановку задачи.
Может переделать мозг? Почему остальных эти файлы не раздражают? Почему никого не раздражает создание файлов с объектным кодом рядом с исходным текстом? Почему раскиданные по рабочей директории поддиректории с файлами проекта от MSVC, CODE BLOCKS, pycharm и т.п. Никого не раздражают? Какие есть альтернативные варианты?

Вы предлагаете сделать глоблаьный кеша компилированного кода ?
http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx
При этом теряется контроль за компилированным кодом, т.е. будет гораздо сложнее удалить кешированный код. Операционная система будет постепенно замусориваться.

В какой момент вашего рабочего процесса вы вообще замечаете что у вас есть *.pyc,*.pyo, *.pyd файлы?

doza_and
Хотел похожее написать.
Но только лаконичнее: “Мне бы Ваши проблемы…”.
Неужели так часто приходится редактировать файлы выбирая их явно, т.е. не через IDE?
Да и редактируя отдельный файл или группу файлов, почти каждая IDE открывает файл или группу файлов автоматически, если они не были явно закрыты в прошлом сеансе, т.е. каждая IDE хранит информацию об открытых ранее файлах для редактирования. Я почти никогда не вижу полную папку проекта. Только когда ее подчищаю от ненужных модулей (которые уже умудрился влить в другие или вообще от них отказался ввиду написания более качественной альтернативы). В остальном даже при копировани использую hg, поэтому не вижу внутренности папки вообще :)

P.S. Может это у меня только так, я не настаиваю :)

Отредактировано 4kpt (Сен. 28, 2013 14:07:55)

doza_and
Почему раскиданные по рабочей директории поддиректории с файлами проекта от MSVC, CODE BLOCKS, pycharm и т.п. Никого не раздражают?

Потому что в IDE их не видно :D

doza_and
> Почему остальных эти файлы не раздражают?
имхо остальным пофигу и/или они не задумываются об этом
вообще 99% людям пофигу на любой процесс… именно поэтому так мало людей репортят баги, участвуют в разработке и т.п.

> Почему раскиданные по рабочей директории поддиректории с файлами проекта от MSVC,
> CODE BLOCKS, pycharm и т.п. Никого не раздражают?
с чего вы взяли?

> Какие есть альтернативные варианты?
дать программисту указать каталог с кэшем и ввести допольнительный <magic> префикс

логка разработчиков питона понятна - они убирали “свалку мусора” из рабочего каталога
и сделали в точности как принято у нас - просто огородили “свалку” “забором”, вместо того чтобы “вывезти мусор”

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

web_pr
дать программисту указать каталог с кэшем и ввести допольнительный <magic> префикс

А мне не нравится этот подход. В этом случае мне надо самостоятельно вводить дополнительные настройки проекта и следить за ними от проекта к проекту или контроллировать в самом проекте если проект будет существенно изменяться.

P.S. Основная идея питона как раз и заключается в уменьшении рутинной работы, а Вы предлагаете мне ее увеличить :) Я пас :)

Отредактировано 4kpt (Сен. 30, 2013 11:21:21)

Классический вариант высасывания проблемы из пальца.
Ставлю 10$, что весь опыт господина web_pr с питоном - максимум сотня строк хелловордов.

А мне не нравится этот подход.

так в чем проблема? можно не использовать - это дело программиста

мне надо самостоятельно вводить дополнительные настройки проекта и следить за ними от проекта к проекту или контроллировать в самом проекте если проект будет существенно изменяться

как и любые другие настройки приложения
отличий нет

Основная идея питона как раз и заключается в уменьшении рутинной работы, а Вы предлагаете мне ее увеличить

придумываете за меня что я предлагаю?
я не предлагаю увеличивать рутину
в любой системе обычно есть параметры для тюнинга, многие их не используют и не знают об их существовании - разве это проблема?
подобные параметры начинают использовать когда упираются в производительность или нужны особые архитектурные решения
кому это не надо - просто используют дефолтовые значения

Классический вариант высасывания проблемы из пальца.

проблема производительности и гибкости для вас “высасывание проблемы из пальца”?
тогда не используйте тюнинг, просто используйте питон “из коробки”

весь опыт господина web_pr с питоном - максимум сотня строк хелловордов

при чем тут мой опыт в питоне?
у вас большой опыт? так расскажите как мне поместить все файлы .pyc в отдельный каталог, опытный вы наш

да, я в питоне новичек… и начал изучать его с надеждой увидеть продуманность, стабильность, скорость
а что вижу? пхп несколько лет назад прям как попал в прошлое
но я пока не сдаюсь
хоть и напоминает все это анекдот про слона