Создайте issue в оригинальном репозитории и опишите проблему. Возможно, автору покажутся разумными ваши доводы и он отформатирует текст в соответсвии с вашими пожеланиями.
На питоне (кэш использовал, чтобы не ждать долго, пока просчитаются итерации для каждого i заново):
from fractions import Fraction
CACHE = {}
def func(y, z):
return 108 - Fraction(815 - Fraction(1500, z), y)
def x(i):
if not i in CACHE:
if i == 0:
result = 4
elif i == 1:
result = Fraction('4.25')
else:
result = func(x(i - 1), x(i - 2))
CACHE[i] = result
return CACHE[i]
def main():
for i in range(100):
print(i, float(x(i)))
if __name__ == '__main__':
main()
Очень часто пишу код именно для себя. Если мы говорим о каком-то проекте, где работает несколько людей, то тоже не вижу особенной проблемы. Обычно проект это virtualenv + requirements.txt, при разворачивании проекта на новой машине, все зависимости, и в том числе, runscript, поставятся автоматом.
Я, честно, плохо понимаю, зачем каждый раз писать «python -m package.module» в вашем проекте для запуска скриптов, если можно договориться написать какой-то запускальщик, который будет решать рутинные операции, специфичные для большинства скриптов этого проекта. В роли запускальщика может выступить в том числе и runscript.
2. На данный момент меня вполне удовлетворяет argparse, идущий в stdlib питона.
Я всё же скорее про себя говорю. Мол были такие-то задачи, я их так-то решил. Это конкретный разговор. О программистах в целом мне рассуждать не интересно. У каждого свои проблемы и каждый решает их по разному. Если кому-то понравится идея runscript, он может использовать эту библиотеку. Если кто-то считает, что она стреляет в ногу или не делает ничего полезного, он не будет её использовать
1. Если я вас правильно понял, я это и делаю, только без docopt :)
2. По поводу optparse вы наверное не совсем поняли меня. Дело в том, что runscript тоже использует optparse, вернее даже не optparse, а argpase. Я в статье писал про это. Сложно или не сложно вам создать файл, кажется ли вам синтаксис django management commands выносимым или нет, я не обсуждаю. Это ваше личное дело. Я просто рассказал, что лично я думаю о django management commands. Вообще этот пункт особо не имеет смысла обсуждать т.к. я использую джангу не во всех проектах, я чуть выше уже говорил об этом.
3. Да, блокировка через lock-файл работает только в пределах одной машины. Меня это устраивает. Фунциональность runscript — это решение моих задач. Задачи лочить выполнение скриптов сразу на нескольких машинах у меня не воникало.
1. Про decopt не понял, не использовал этот пакет. Можно подробнее?
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)
FileHeap асинхронный? Какую библиотеку используете для асинхронности?
* Запускается ли в ReactoOS CPython?
* Есть ли возможность работать с ReactOS сервером через ssh?
Вывод:
Я, честно, плохо понимаю, зачем каждый раз писать «python -m package.module» в вашем проекте для запуска скриптов, если можно договориться написать какой-то запускальщик, который будет решать рутинные операции, специфичные для большинства скриптов этого проекта. В роли запускальщика может выступить в том числе и runscript.
Я всё же скорее про себя говорю. Мол были такие-то задачи, я их так-то решил. Это конкретный разговор. О программистах в целом мне рассуждать не интересно. У каждого свои проблемы и каждый решает их по разному. Если кому-то понравится идея runscript, он может использовать эту библиотеку. Если кто-то считает, что она стреляет в ногу или не делает ничего полезного, он не будет её использовать
2. По поводу optparse вы наверное не совсем поняли меня. Дело в том, что runscript тоже использует optparse, вернее даже не optparse, а argpase. Я в статье писал про это. Сложно или не сложно вам создать файл, кажется ли вам синтаксис django management commands выносимым или нет, я не обсуждаю. Это ваше личное дело. Я просто рассказал, что лично я думаю о django management commands. Вообще этот пункт особо не имеет смысла обсуждать т.к. я использую джангу не во всех проектах, я чуть выше уже говорил об этом.
3. Да, блокировка через lock-файл работает только в пределах одной машины. Меня это устраивает. Фунциональность runscript — это решение моих задач. Задачи лочить выполнение скриптов сразу на нескольких машинах у меня не воникало.
2. Во-первых, django я не в каждом проекте использую. Во-вторых, мне не нравятся django management commands. Мне нравится писать простые скрипты с одной функцией и складывать их в одну директорию в проекте. В случае джанго нужно запрятать скрипты подальше — в management/commands каталог какого-либо приложения. Да и сами скрипты становятся сложнее. Сравните:
django
runscript
3. Не очень понял, что вы имели в виду. Можно пример выстрела?