Найти - Пользователи
Полная версия: Отключить создание файлов .pyc
Начало » Python для новичков » Отключить создание файлов .pyc
1 2 3 4
masterito
И в чем же преимущество решения, которое вы предлагаете?
Я, кроме как “мне так больше нравится”, аргументов в пользу вашего предложения не услышал.
web_pr
можно увеличить быстродействие вынеся .pyc файлы на диск в памяти
если с памятью беда - можно даже управлять самостоятельно временем жизни этого кэша

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

это еще даст ограничение доступа к исходникам на рабочих нодах (в случае взлома)

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

при массовом перемещении модулей и удалении сложно будет забыть удалить кэш
а ведь он (старый кэш) может подхватиться даже при отсутствии исходника модуля?
т.е. повысится удобство поддержки большого проекта

ну и конечно красота решения и отсутствие “мусора” в рабочих каталогах
это самый маленький фактор, но он присутствует
ведь не зря .pyc файлы переместили из рабочего каталога в подкаталог - значит этот фактор тоже учитывается разработчиками питона
иначе оставили бы все как прежде и говорили про скрытие файлов в IDE

часть вещей можно сделать ручками и самому, но как говорили выше “основная идея питона как раз и заключается в уменьшении рутинной работы”
masterito
web_pr
ожно увеличить быстродействие вынеся .pyc файлы на диск в памятиесли с памятью беда - можно даже управлять самостоятельно временем жизни этого кэша
А чем кеш файловой системы не нравится? Часто используемые файлы у вас итак в памяти располагаются. На практике никакого смысла в этом нет.

web_pr
можно быстрее и проще распространять .pyc файлы по нодам без перекидывания исходников и создания кучи каталогов
быстрее и проще - значит меньше точек отказа, т.е. повысится общая надежность решенияэто еще даст ограничение доступа к исходникам на рабочих нодах (в случае взлома)
Открою секрет - из pyc файла очень легко получить исходник, так что опять же не вижу никакого преимущества. Тем же самым образом можно распространять дерево исходников. Плюс каким образом вы будете поддерживать пакеты и адресные пространства? Как определить что должно импортироваться первым - стандартный list или мой list?

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

web_pr
при массовом перемещении модулей и удалении сложно будет забыть удалить кэша ведь он (старый кэш) может подхватиться даже при отсутствии исходника модуля?т.е. повысится удобство поддержки большого проекта
Удалите все .pyc файлы - в Unix это делается одной простой командой. Опять же сомнительное преимущество - вероятность того, что вы не заметите файл в какой-то центральной директории в которой распологаются весь кеш гораздо выше, чем то, что вы не заметите .pyc файл в текущей директории.

web_pr
ну и конечно красота решения и отсутствие “мусора” в рабочих каталогах это самый маленький фактор, но он присутствуетведь не зря .pyc файлы переместили из рабочего каталога в подкаталог - значит этот фактор тоже учитывается разработчиками питона
иначе оставили бы все как прежде и говорили про скрытие файлов в IDE
часть вещей можно сделать ручками и самому, но как говорили выше “основная идея питона как раз и заключается в уменьшении рутинной работы”
Опять же это не аргумент в пользу помещения всех .pyc файлов в одну директорию.
ZZZ
web_pr
в любой системе обычно есть параметры для тюнинга, многие их не используют и не знают об их существовании - разве это проблема?
Да. Потому что чаще всего эти параметры начинают крутить те, кому они не нужны и, когда они что-нить сломают, матеряться на продукт, а не на свои кривые руки. А те, кому это действительно надо, залезут в исходники и сделают всё, что им нужно.

Опус с жирными выделениями я не смог прочитать. Осилил только две первые строчки: вытаскивать код на RAM-диск, это просто феерия!
web_pr, “не надо считать профессиональных программистов глупее себя” – это первая заповедь, которую тебе стоит выучить, прежде чем упрекать что-либо в чём-либо.
4kpt
web_pr
Бросьте это гиблое дело. Если Вы ищете совершенства, то Вы совсем не по адресу. Совершенство у всех объективно и не существует общих лекал. Вы же пытаетесь нас вменить, что Ваше представление является единственно верным.

Простите, но на начальном этапе, еще не освоив язык Вы начинаете заниматься фигней. И опыт Ваш тут очень даже при чем. Более опытный программист, даже если он знает другой язык, таким заниматься не будет в принципе. На это у него не будет времени.

Это как сказать:
“Почему описание функции начинается с ”def“ а не с ”df“, ведь так же было бы короче. Что за лаконичность, если мне приходится вводить лишнюю букву ”е“. Я от языка ожидал совсем другого. Язык - полный дрэг. Я от него откажусь” :)

ZZZ
вытаскивать код на RAM-диск, это просто феерия!
Меня тоже это улыбнуло…

И последнее
ну и конечно красота решения и отсутствие “мусора” в рабочих каталогах
В Вашем случае это не главная проблема. Даже если Вы уберете все лишние файлы, то красоты от этого Вашему решению не прибавится ввиду малого опыта и, как следствие, низкого качества итогового результата. Сами решения будут на первых порах не очень (и это не только у Вас, это у всех). Но других программистов больше волнуют проблемы написания качественного кода, чем удаление лишнего “мусора”. Поэтому при равных временных затратах через определенный промежуток времени их решения будут на порядок лучше Ваших даже при наличии в их проектах лишних файлов.


P.S. Не очень адекватно свое недовольство подходами принятыми в языке выражать на форуме поклонников этого языка. Возраст, видимо…

P.S.S. Вы лучше не обижайтесь, а прислушайтесь к тому, что говорят Ваши более опытные коллеги. Ведь на форуме не стоит задача Вас обмануть или направить на неверный путь. Так как форум - это бесплатная социальная инициатива каждого учасника - люди здесь пытаются друг другу помочь…
malya
Гы. Начал тему, а устроили срач.
web_pr
masterito
А чем кеш файловой системы не нравится? Часто используемые файлы у вас итак в памяти располагаются. На практике никакого смысла в этом нет.
тем, что я хочу контролировать что у меня находится в кэше

masterito
Тем же самым образом можно распространять дерево исходников.
можно, но ключевое слово было проще

masterito
И какое отношение это имеет к хранению файлов в едином каталоге?
прямое

masterito
вероятность того, что вы не заметите файл в какой-то центральной директории в которой распологаются весь кеш гораздо выше, чем то, что вы не заметите .pyc файл в текущей директории.
не в “текущей директории”, а в “поддиректории”
т.е. вероятности довольно разные

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

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

ZZZ
Опус с жирными выделениями я не смог прочитать. Осилил только две первые строчки: вытаскивать код на RAM-диск, это просто феерия!
web_pr, “не надо считать профессиональных программистов глупее себя” – это первая заповедь, которую тебе стоит выучить, прежде чем упрекать что-либо в чём-либо.
даже не знаю что ответить, могу только посочуствовать такой логике

2 4kpt
мне сложно понять - вы под воздействием препаратов или действительно такое думаете
могу только посоветовать не судить о других людях по себе


4kpt_II
web_pr
Вы проснулись? Все про эту тему и про Ваше подростковое неудовлетворение уже давно забыли…

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

Слишком еще юны, чтобы мне советовать.

P.S. И еще

web_pr
даже не знаю что ответить, могу только посочуствовать такой логике


Логика не может быть “такой” или “не такой”. Она либо есть, либо ее нет. Если бы Вы чаще ходили на уроки, то Вы бы про это уже знали.
web_pr
4kpt_II
ваше мнение меня не интересует
нет желание слушать прыщавых юнцов с различными комплексами (поверьте, по вашим сообщениям это очень заметно) - обратитесь лучше к специалисту должной специализации

Singularity
web_pr
нет желание слушать прыщавых юнцов с различными комплексами (поверьте, по вашим сообщениям это очень заметно)
интересно, а я похож прищавого юнца ? Все мои сообщения можно посмотреть по http://python.su/forum/search/?action=show_user&user_id=6609
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB