Comments 26
Когда кэш заполнен и необходимо сохранить новый результат, наименее
использованный результат вытесняется из кэша, чтобы освободить место для
нового. Это называется стратегией наименее использованного результата
(LRU).
Какой-то супернеудачный перевод. Ну не придумывайте вы своих терминов: во всём гугле нет ни одного результата по запросу "стратегия наименее использованного результата" (в кавычках).
А можно тупой вопрос? Почему в Питоне используются декораторы, а не просто функции высших порядков?
Это просто синтаксический сахар поверх ФВП
Удобство. Есть у вас функция foo и теперь вы её каждый вызов затрейсить хотите. Навесили декоратор и готово. А так вам придётся fooWithoutTracing писать и её уже из foo вызывать обёрнутую в функцию трассировки. Ну или везде в коде foo() на trace(foo()) заменять, что может быть совсем неудобно.
Просто функциональщина в питоне это моветон, а декораторы они в своё время сделали под впечатлением от аннотаций в java.
С помощью синтаксиса с собачкой нужно писать гораздо меньше букв.
По сути применить декоратор
@contextmanager
def file_manager:
...
Это то же самое, что написать
file_manager = contextmanager(file_manager)
Первый вариант гораздо удобнее поэтому всем им и пользуются.
А по сути, как уже писали, декоратор - это обычная ФВП.
В Python из функциональных языков много всяких моментов надергано.
А по сути, как уже писали, декоратор - это обычная ФВП.
Да, я примерно также и рассказал на одном собеседовании, которое не собирался проходить. :-) Добавив, что не очень понимаю, почему пользуются декораторами, а не ФП, как в Haskell.
Вообще спасибо за коммент: посмотрел пристальнее на LISP, из которого все эти with и притащили в разные языки, там with-open-file — это макрос, то есть, это где-то посередине между ФВП (вычисляющейся в runtime) и декоратором (спец. средство языка).
@atexit.register - этим только кормить антипаттерны
Раскройте пожалуйста эту тему подробднее, какие именно антипаттерны и чем их кормить?
Ну во-первых, для чего. Сможете придумать кейс? Гораздо прозрачнее в конце программы вызвать необходимую вам функцию, чем придумывать какие-то декораторы(хорошо хоть не целый фреймворк:)). А потом запрятать эту задекорированную функцию в дебрях приложения, забыть про нее и не понимать откуда у вас взялась логика по выходу из приложения. А ещё может быть так, что эта функция при одной логике будет импортироваться, при другой нет, соответственно, код при выходе из приложения то будет отрабатывать, то нет. В общем, "веселая" отладка вам будет обеспечена.
Выглядит как обертка над стандартной POSIX-функцией “atexit”
А нужна она, очевидно, в случаях когда у вас нет доступа к main(). Например вы пишете библиотеку. Вам нужно освободить ресурсы при выходе (дописать в файлы итп). Как сделать так чтобы ваша библиотека нормально работала в программах, вызывающих exit()?
Спасибо
Гораздо прозрачнее в конце программы вызвать необходимую вам функцию
Половина людей забудет туда try: finally добавить. Я бы смотрел в сторону контекстных менеджеров.
Похожий подход используется в https://docs.python.org/3/library/signal.html?highlight=signal#signal.signal, там нет декоратора, но в общем смысл примерно тотже. Только вот через код это не обработаетшь.
Потому что, порой, программы завершаются через KeyboardInterrupt или, того хуже, через SystemExit не по воле разработчика, и вот тогда нужно выполнить ряд действий, чтобы закрылось всё без накладок. Наоборот очень полезная штука — взял себе на заметку.
Мы наспавнили тредов и повесили их шатдаун на atexit.register . Что не так?
тредов? daemon=true и сами закроются на выходе
Daemon threads are abruptly stopped at shutdown. Their resources (such as open files, database transactions, etc.) may not be released properly. If you want your threads to stop gracefully, make them non-daemonic and use a suitable signalling mechanism such as an
Event.
https://docs.python.org/3/library/threading.html#thread-objects
В примере для contextmanager, думаю, стоит добавить try...finally.
Про lru_cache: чтобы работало, нужно чтобы все аргументы функции были хэшируемыми.
Про декоратор @property: его назначение не только для организации сеттеров и геттеров, также используется для получения доступа к методу класса как к атрибуту. Т.е. можно будет вызывать его в виде Class.property, без скобок и т.д. Иногда очень упрощает понимание/нейминг
Откровенно говоря питон проигрывает шарпу в удобстве разработки, конструкции размытые, контроля целостности толком нет. Ну есть конечно хорошие моменты, но в общем проигрывает
В примерах много использования кэша. Теперь нужен ликбез на тему как не забить кэш 😄
6 Python декораторов, которые значительно упростят ваш код