И в чем же преимущество решения, которое вы предлагаете?
Я, кроме как “мне так больше нравится”, аргументов в пользу вашего предложения не услышал.


web_prА чем кеш файловой системы не нравится? Часто используемые файлы у вас итак в памяти располагаются. На практике никакого смысла в этом нет.
ожно увеличить быстродействие вынеся .pyc файлы на диск в памятиесли с памятью беда - можно даже управлять самостоятельно временем жизни этого кэша
web_prОткрою секрет - из pyc файла очень легко получить исходник, так что опять же не вижу никакого преимущества. Тем же самым образом можно распространять дерево исходников. Плюс каким образом вы будете поддерживать пакеты и адресные пространства? Как определить что должно импортироваться первым - стандартный list или мой list?
можно быстрее и проще распространять .pyc файлы по нодам без перекидывания исходников и создания кучи каталогов
быстрее и проще - значит меньше точек отказа, т.е. повысится общая надежность решенияэто еще даст ограничение доступа к исходникам на рабочих нодах (в случае взлома)
web_prИ какое отношение это имеет к хранению файлов в едином каталоге?
можно настроить права так, что .pyc Файлы сможет генерить только определенный пользовательэто повысит безопасность, т.к. даже при взломе скрипта нельзя будет модифицировать код модулей и их кэша
web_prУдалите все .pyc файлы - в Unix это делается одной простой командой. Опять же сомнительное преимущество - вероятность того, что вы не заметите файл в какой-то центральной директории в которой распологаются весь кеш гораздо выше, чем то, что вы не заметите .pyc файл в текущей директории.
при массовом перемещении модулей и удалении сложно будет забыть удалить кэша ведь он (старый кэш) может подхватиться даже при отсутствии исходника модуля?т.е. повысится удобство поддержки большого проекта
web_prОпять же это не аргумент в пользу помещения всех .pyc файлов в одну директорию.
ну и конечно красота решения и отсутствие “мусора” в рабочих каталогах это самый маленький фактор, но он присутствуетведь не зря .pyc файлы переместили из рабочего каталога в подкаталог - значит этот фактор тоже учитывается разработчиками питона
иначе оставили бы все как прежде и говорили про скрытие файлов в IDE
часть вещей можно сделать ручками и самому, но как говорили выше “основная идея питона как раз и заключается в уменьшении рутинной работы”
web_prДа. Потому что чаще всего эти параметры начинают крутить те, кому они не нужны и, когда они что-нить сломают, матеряться на продукт, а не на свои кривые руки. А те, кому это действительно надо, залезут в исходники и сделают всё, что им нужно.
в любой системе обычно есть параметры для тюнинга, многие их не используют и не знают об их существовании - разве это проблема?
ZZZМеня тоже это улыбнуло…
вытаскивать код на RAM-диск, это просто феерия!
masteritoтем, что я хочу контролировать что у меня находится в кэше
А чем кеш файловой системы не нравится? Часто используемые файлы у вас итак в памяти располагаются. На практике никакого смысла в этом нет.
masteritoможно, но ключевое слово было проще
Тем же самым образом можно распространять дерево исходников.
masteritoпрямое
И какое отношение это имеет к хранению файлов в едином каталоге?
masteritoне в “текущей директории”, а в “поддиректории”
вероятность того, что вы не заметите файл в какой-то центральной директории в которой распологаются весь кеш гораздо выше, чем то, что вы не заметите .pyc файл в текущей директории.
masteritoдля разработчиков питона - аргумент, и они это уже показали перекинув файлы в поддиректорию
Опять же это не аргумент в пользу помещения всех .pyc файлов в одну директорию.
ZZZхороший подход
Да. Потому что чаще всего эти параметры начинают крутить те, кому они не нужны и, когда они что-нить сломают, матеряться на продукт, а не на свои кривые руки. А те, кому это действительно надо, залезут в исходники и сделают всё, что им нужно.

ZZZдаже не знаю что ответить, могу только посочуствовать такой логике
Опус с жирными выделениями я не смог прочитать. Осилил только две первые строчки: вытаскивать код на RAM-диск, это просто феерия!
web_pr, “не надо считать профессиональных программистов глупее себя” – это первая заповедь, которую тебе стоит выучить, прежде чем упрекать что-либо в чём-либо.
web_pr
могу только посоветовать не судить о других людях по себе
web_pr
даже не знаю что ответить, могу только посочуствовать такой логике
web_prинтересно, а я похож прищавого юнца ?
нет желание слушать прыщавых юнцов с различными комплексами (поверьте, по вашим сообщениям это очень заметно)
Все мои сообщения можно посмотреть по http://python.su/forum/search/?action=show_user&user_id=6609