Comments 26
Псст, парень,
Только никому!
if __name__ == '__main__':Только никому!
Не понял.
Имелось в виду, что это условие позволяет запускать скрипт без дополнительных приблуд:
как-то так
как-то так
Это условие
позволяет как раз *не* запускать фунцию main(), в том случае, если мы импортировали модуль скрипта в другом модуле. Именно эту проблему, решает вышеприведённое условие.
Чтобы запустить на выполнение фунцию main, достаточно её запустить :)) Без всяких условий.
if __name__ == '__main__':
main()
позволяет как раз *не* запускать фунцию main(), в том случае, если мы импортировали модуль скрипта в другом модуле. Именно эту проблему, решает вышеприведённое условие.
Чтобы запустить на выполнение фунцию main, достаточно её запустить :)) Без всяких условий.
main()
Как это решает проблему, описанную выше?
program.py:
scripts/script.py:
├── program.py
└── scripts
└── script.py
program.py:
def hello_world():
print "Hello, world!"
scripts/script.py:
import program
def actions():
program.hello_world()
actions()
Видимо, проблема настолько не очевидна, что многие, включая меня, вообще никакой проблемы не видят.
Может я что-то не понимаю?
В чем собственно проблема выполнить скрипт на питоне?
Может я что-то не понимаю?
В чем собственно проблема выполнить скрипт на питоне?
Если прописать python scripts/script.py вылетит ImportError, говорящий что нету модуля program в пределе досягаемости. Если я правильно понял, автор решает именно этот кейс.
Так вот я и спросил, как
Решает эту проблему.
Так вот я и спросил, как
if __name__ == '__main__':
Решает эту проблему.
python -m scripts/script.py?
Тфу, python -m scripts.script
Действительно, нужно просто упаковать скрипт в пакет.
Не знал, что так можно. Спасибо!
Не знал, что так можно. Спасибо!
По сути ключ -m добавляет текущую директорию в sys.path
Для меня это ничего не меняет. У меня есть альтернатива:
Вариант 1:
Вариант 2:
Я выбираю вариант 2 — нужно меньше букв печатать, как в скриптах, так и в консоли. Для меня это важно. И мне очень приятно, что я экономлю это время. Как я уже заметил в статье, ничего революционного пакет runscript не делает, но то малое, что он делает, очень удобно.
Кроме, краткости, вариант 2 предоставляет упрощённую обработку аргументов командной строки и другие плюшки, о которых я написал в статье.
Я просто поделился тем, как запускаю скрипты в своих проектах. Никому ничего не навязываю и не говорю, что мой способ самый «лучший» (что бы это ни значило).
Вариант 1:
def main():
pass
if __name__ == '__main__':
main()
$ python -m script.preved
Вариант 2:
def main(**kwargs):
pass
$ run preved
Я выбираю вариант 2 — нужно меньше букв печатать, как в скриптах, так и в консоли. Для меня это важно. И мне очень приятно, что я экономлю это время. Как я уже заметил в статье, ничего революционного пакет runscript не делает, но то малое, что он делает, очень удобно.
Кроме, краткости, вариант 2 предоставляет упрощённую обработку аргументов командной строки и другие плюшки, о которых я написал в статье.
Я просто поделился тем, как запускаю скрипты в своих проектах. Никому ничего не навязываю и не говорю, что мой способ самый «лучший» (что бы это ни значило).
> Я выбираю вариант 2
Это «неправильный» выбор. Если вы планируете запускать скрипт из консоли, то надо писать
хотя бы потому, что
не требует установки пакета для работы.
Исключение — вы пишете код для себя и никто никогда не будет с ним работать и запускаться он будет на одной машине.
Это «неправильный» выбор. Если вы планируете запускать скрипт из консоли, то надо писать
if __name__ == "__main__":
хотя бы потому, что
$ python -m script.preved
не требует установки пакета для работы.
Исключение — вы пишете код для себя и никто никогда не будет с ним работать и запускаться он будет на одной машине.
Очень часто пишу код именно для себя. Если мы говорим о каком-то проекте, где работает несколько людей, то тоже не вижу особенной проблемы. Обычно проект это virtualenv + requirements.txt, при разворачивании проекта на новой машине, все зависимости, и в том числе, runscript, поставятся автоматом.
Я, честно, плохо понимаю, зачем каждый раз писать «python -m package.module» в вашем проекте для запуска скриптов, если можно договориться написать какой-то запускальщик, который будет решать рутинные операции, специфичные для большинства скриптов этого проекта. В роли запускальщика может выступить в том числе и runscript.
Я, честно, плохо понимаю, зачем каждый раз писать «python -m package.module» в вашем проекте для запуска скриптов, если можно договориться написать какой-то запускальщик, который будет решать рутинные операции, специфичные для большинства скриптов этого проекта. В роли запускальщика может выступить в том числе и runscript.
Вы знаете несколько минусов:
1. Взять docopt и сделать так, чтобы он делал импорт нужного модуля и вызов main. Весьма просто, и дело одного абзаца
2. Если у вас уже есть django — то там есть стандартные commands с интерфейсом argparse. Зачем еще runscript?
3. lock-file это наверно хорошая штука если у вас только 1 сервер, который выполняет этот код. Например, если на уровне кода нет разделения, то любой девелоперская машина выполнит тот же код что и на проде — итог, очень просто выстрелить себе в ногу.
1. Взять docopt и сделать так, чтобы он делал импорт нужного модуля и вызов main. Весьма просто, и дело одного абзаца
2. Если у вас уже есть django — то там есть стандартные commands с интерфейсом argparse. Зачем еще runscript?
3. lock-file это наверно хорошая штука если у вас только 1 сервер, который выполняет этот код. Например, если на уровне кода нет разделения, то любой девелоперская машина выполнит тот же код что и на проде — итог, очень просто выстрелить себе в ногу.
1. Про decopt не понял, не использовал этот пакет. Можно подробнее?
2. Во-первых, django я не в каждом проекте использую. Во-вторых, мне не нравятся django management commands. Мне нравится писать простые скрипты с одной функцией и складывать их в одну директорию в проекте. В случае джанго нужно запрятать скрипты подальше — в management/commands каталог какого-либо приложения. Да и сами скрипты становятся сложнее. Сравните:
django
runscript
3. Не очень понял, что вы имели в виду. Можно пример выстрела?
2. Во-первых, django я не в каждом проекте использую. Во-вторых, мне не нравятся django management commands. Мне нравится писать простые скрипты с одной функцией и складывать их в одну директорию в проекте. В случае джанго нужно запрятать скрипты подальше — в management/commands каталог какого-либо приложения. Да и сами скрипты становятся сложнее. Сравните:
django
from django.core.management.base import BaseCommand
from optparse import make_option
class Command(BaseCommand):
option_list = BaseCommand.option_list + (
make_option('-w', '--who'),
)
def handle(self, who, *args, **options):
print(who)
runscript
def setup_arg_parser(parser):
parser.add_argument('-w', '--who')
def main(who, **kwargs):
print(who)
3. Не очень понял, что вы имели в виду. Можно пример выстрела?
Ok,
1. Вот github.com/docopt/docopt, предлагается просто завести первым аргументом, что-то и делать согласно ему import_module().main(args).
2. Ну так ок, это не так сложно вроде в папку commands бросить файл, синтаксис я бы не сказал что невыносимый. Только еще плюсом идет факт, что там стоит немаленького размера optparse, котором намного больше функций, чем runscript.add_argument.
3. Я имел что lock-file работает только на одной машине, у другого сервера lock-file нет и следовательно ваш механизм блокировки не работает.
1. Вот github.com/docopt/docopt, предлагается просто завести первым аргументом, что-то и делать согласно ему import_module().main(args).
2. Ну так ок, это не так сложно вроде в папку commands бросить файл, синтаксис я бы не сказал что невыносимый. Только еще плюсом идет факт, что там стоит немаленького размера optparse, котором намного больше функций, чем runscript.add_argument.
3. Я имел что lock-file работает только на одной машине, у другого сервера lock-file нет и следовательно ваш механизм блокировки не работает.
1. Если я вас правильно понял, я это и делаю, только без docopt :)
2. По поводу optparse вы наверное не совсем поняли меня. Дело в том, что runscript тоже использует optparse, вернее даже не optparse, а argpase. Я в статье писал про это. Сложно или не сложно вам создать файл, кажется ли вам синтаксис django management commands выносимым или нет, я не обсуждаю. Это ваше личное дело. Я просто рассказал, что лично я думаю о django management commands. Вообще этот пункт особо не имеет смысла обсуждать т.к. я использую джангу не во всех проектах, я чуть выше уже говорил об этом.
3. Да, блокировка через lock-файл работает только в пределах одной машины. Меня это устраивает. Фунциональность runscript — это решение моих задач. Задачи лочить выполнение скриптов сразу на нескольких машинах у меня не воникало.
2. По поводу optparse вы наверное не совсем поняли меня. Дело в том, что runscript тоже использует optparse, вернее даже не optparse, а argpase. Я в статье писал про это. Сложно или не сложно вам создать файл, кажется ли вам синтаксис django management commands выносимым или нет, я не обсуждаю. Это ваше личное дело. Я просто рассказал, что лично я думаю о django management commands. Вообще этот пункт особо не имеет смысла обсуждать т.к. я использую джангу не во всех проектах, я чуть выше уже говорил об этом.
3. Да, блокировка через lock-файл работает только в пределах одной машины. Меня это устраивает. Фунциональность runscript — это решение моих задач. Задачи лочить выполнение скриптов сразу на нескольких машинах у меня не воникало.
1. да
2. используйте docopt или click (http://click.pocoo.org/3/)
3. да
Ну мы говорим не только о Вас, а о нас программистах в целом.
2. используйте docopt или click (http://click.pocoo.org/3/)
3. да
Ну мы говорим не только о Вас, а о нас программистах в целом.
2. На данный момент меня вполне удовлетворяет argparse, идущий в stdlib питона.
Я всё же скорее про себя говорю. Мол были такие-то задачи, я их так-то решил. Это конкретный разговор. О программистах в целом мне рассуждать не интересно. У каждого свои проблемы и каждый решает их по разному. Если кому-то понравится идея runscript, он может использовать эту библиотеку. Если кто-то считает, что она стреляет в ногу или не делает ничего полезного, он не будет её использовать
Я всё же скорее про себя говорю. Мол были такие-то задачи, я их так-то решил. Это конкретный разговор. О программистах в целом мне рассуждать не интересно. У каждого свои проблемы и каждый решает их по разному. Если кому-то понравится идея runscript, он может использовать эту библиотеку. Если кто-то считает, что она стреляет в ногу или не делает ничего полезного, он не будет её использовать
В django_extensions есть команда runscript
Однажды я взял и потратил день на изучение virtualenv и setuptools. С тех пор на тех кто манипулирует sys.path я смотрю свысока
TL;DR.
Вопрос в чем — в случае падения python-скрипта lock-файл автоматически удалится? Если нет, то это баг, т.к. это блокирует последующие выполнения.
Вопрос в чем — в случае падения python-скрипта lock-файл автоматически удалится? Если нет, то это баг, т.к. это блокирует последующие выполнения.
Sign up to leave a comment.
Runscript — утилита для запуска python скриптов