Форум сайта python.su
0
И в чем же преимущество решения, которое вы предлагаете?
Я, кроме как “мне так больше нравится”, аргументов в пользу вашего предложения не услышал.
Офлайн
0
можно увеличить быстродействие вынеся .pyc файлы на диск в памяти
если с памятью беда - можно даже управлять самостоятельно временем жизни этого кэша
можно быстрее и проще распространять .pyc файлы по нодам без перекидывания исходников и создания кучи каталогов
быстрее и проще - значит меньше точек отказа, т.е. повысится общая надежность решения
это еще даст ограничение доступа к исходникам на рабочих нодах (в случае взлома)
можно настроить права так, что .pyc файлы сможет генерить только определенный пользователь
это повысит безопасность, т.к. даже при взломе скрипта нельзя будет модифицировать код модулей и их кэша
при массовом перемещении модулей и удалении сложно будет забыть удалить кэш
а ведь он (старый кэш) может подхватиться даже при отсутствии исходника модуля?
т.е. повысится удобство поддержки большого проекта
ну и конечно красота решения и отсутствие “мусора” в рабочих каталогах 
это самый маленький фактор, но он присутствует
ведь не зря .pyc файлы переместили из рабочего каталога в подкаталог - значит этот фактор тоже учитывается разработчиками питона
иначе оставили бы все как прежде и говорили про скрытие файлов в IDE
часть вещей можно сделать ручками и самому, но как говорили выше “основная идея питона как раз и заключается в уменьшении рутинной работы” 
Отредактировано web_pr (Сен. 30, 2013 15:53:34)
Офлайн
0
web_prА чем кеш файловой системы не нравится? Часто используемые файлы у вас итак в памяти располагаются. На практике никакого смысла в этом нет.
ожно увеличить быстродействие вынеся .pyc файлы на диск в памятиесли с памятью беда - можно даже управлять самостоятельно временем жизни этого кэша
web_prОткрою секрет - из pyc файла очень легко получить исходник, так что опять же не вижу никакого преимущества. Тем же самым образом можно распространять дерево исходников. Плюс каким образом вы будете поддерживать пакеты и адресные пространства? Как определить что должно импортироваться первым - стандартный list или мой list?
можно быстрее и проще распространять .pyc файлы по нодам без перекидывания исходников и создания кучи каталогов
быстрее и проще - значит меньше точек отказа, т.е. повысится общая надежность решенияэто еще даст ограничение доступа к исходникам на рабочих нодах (в случае взлома)
web_prИ какое отношение это имеет к хранению файлов в едином каталоге?
можно настроить права так, что .pyc Файлы сможет генерить только определенный пользовательэто повысит безопасность, т.к. даже при взломе скрипта нельзя будет модифицировать код модулей и их кэша
web_prУдалите все .pyc файлы - в Unix это делается одной простой командой. Опять же сомнительное преимущество - вероятность того, что вы не заметите файл в какой-то центральной директории в которой распологаются весь кеш гораздо выше, чем то, что вы не заметите .pyc файл в текущей директории.
при массовом перемещении модулей и удалении сложно будет забыть удалить кэша ведь он (старый кэш) может подхватиться даже при отсутствии исходника модуля?т.е. повысится удобство поддержки большого проекта
web_prОпять же это не аргумент в пользу помещения всех .pyc файлов в одну директорию.
ну и конечно красота решения и отсутствие “мусора” в рабочих каталогах это самый маленький фактор, но он присутствуетведь не зря .pyc файлы переместили из рабочего каталога в подкаталог - значит этот фактор тоже учитывается разработчиками питона
иначе оставили бы все как прежде и говорили про скрытие файлов в IDE
часть вещей можно сделать ручками и самому, но как говорили выше “основная идея питона как раз и заключается в уменьшении рутинной работы”
Офлайн
26
web_prДа. Потому что чаще всего эти параметры начинают крутить те, кому они не нужны и, когда они что-нить сломают, матеряться на продукт, а не на свои кривые руки. А те, кому это действительно надо, залезут в исходники и сделают всё, что им нужно.
в любой системе обычно есть параметры для тюнинга, многие их не используют и не знают об их существовании - разве это проблема?
Офлайн
63
web_pr
Бросьте это гиблое дело. Если Вы ищете совершенства, то Вы совсем не по адресу. Совершенство у всех объективно и не существует общих лекал. Вы же пытаетесь нас вменить, что Ваше представление является единственно верным.
Простите, но на начальном этапе, еще не освоив язык Вы начинаете заниматься фигней. И опыт Ваш тут очень даже при чем. Более опытный программист, даже если он знает другой язык, таким заниматься не будет в принципе. На это у него не будет времени.
Это как сказать:
“Почему описание функции начинается с ”def“ а не с ”df“, ведь так же было бы короче. Что за лаконичность, если мне приходится вводить лишнюю букву ”е“. Я от языка ожидал совсем другого. Язык - полный дрэг. Я от него откажусь” :)
ZZZМеня тоже это улыбнуло…
вытаскивать код на RAM-диск, это просто феерия!
Отредактировано 4kpt (Сен. 30, 2013 17:31:04)
Офлайн
1
Гы. Начал тему, а устроили срач.
Офлайн
0
masteritoтем, что я хочу контролировать что у меня находится в кэше
А чем кеш файловой системы не нравится? Часто используемые файлы у вас итак в памяти располагаются. На практике никакого смысла в этом нет.
masteritoможно, но ключевое слово было проще
Тем же самым образом можно распространять дерево исходников.
masteritoпрямое
И какое отношение это имеет к хранению файлов в едином каталоге?
masteritoне в “текущей директории”, а в “поддиректории”
вероятность того, что вы не заметите файл в какой-то центральной директории в которой распологаются весь кеш гораздо выше, чем то, что вы не заметите .pyc файл в текущей директории.
masteritoдля разработчиков питона - аргумент, и они это уже показали перекинув файлы в поддиректорию
Опять же это не аргумент в пользу помещения всех .pyc файлов в одну директорию.
ZZZхороший подход
Да. Потому что чаще всего эти параметры начинают крутить те, кому они не нужны и, когда они что-нить сломают, матеряться на продукт, а не на свои кривые руки. А те, кому это действительно надо, залезут в исходники и сделают всё, что им нужно.

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