Если вы используете класс, методы которого реализуют логику многих эндпоинтов, вам удобнее указать для каждого метода тот набор проверок, который вам необходим, одной из них может быть проверка, что пользователь авторизован, на какой-то ручке вы хотите проверить, что пользователь авторизован и имеет ту или иную роль, где-то вы хотите проверить какое либо значение из cookie, в данном случае вам удобнее всего повесить нужный набор декораторов на нужные вам методы. Альтернативой является наследование от какого-то другого класса и указание например общей для всех эндпоинтов проверки авторизации, что может не подходить для решения задачи, либо вам нужно иметь какой-то атрибут с маппингом, проверок, которые нужны для того или иного метода, что является менее явным. Либо вы можете написать для каждого эндпоинта свой класс, что делать дольше.
Если вы реализуете эндпоинты на базе функций, то вам всегда удобнее использовать декораторы
Я ссылался на статью про замыкание и в первом упоминании пространства имён я ссылаюсь на статью о нем. Возможно стоило раскрыть эту тему в одном из разделов статьи
Я не вижу противопоказаний к применению декораторов для проверок авторизации, особенно если у вас нет никакой сложной логики, или необходимости поддерживать множество вариантов авторизации для одного и того же эндпоинта, поэтому неудачным данный пример я все же назвать не могу
И потому что это удобный синтаксический сахар, который улучшает читаемость кода
И потому что, он полезен тем, что внутри декоратора есть свои уровни пространств имен, доступ к которым есть во вложенных в декоратор функциях, но это в любом случае свойство функций и сам синтаксический сахар тут не причем
Я предполагал, что читателям, не имеющим большого багажа опыта python разработки за спиной, может быть интересно, где чаще всего используется объект рассмотрения статьи, никакого более глубокого замысла не было. Думаю, что если бы статью писал другой человек, данный список возможно бы отличался, но по большей части наблюдалось бы пересечение элементов списка
Не вижу противоречий между, "применение имеет смысл" из статьи и "имеет место быть" из комментария выше
Под продвинутым использованием лично я подразумевал варианты и способы использования выходящие за рамки обзора большинства статей на аналогичную тему, что, на мой взгляд этим и является
По поводу приведения в пример потому что есть в библиотеке, не вижу тут ничего плохого, в плане того, что вы спокойно можете посмотреть реализацию в исходниках и при необходимости переделать под свои нужды
Опять же, в статье есть оглавление, в котором не указан подробный разбор конкретно этой темы.
Если это действительно важная тема требующая более детального рассмотрения, я с радостью освещу ее в одной из следующих статей
Что касается ссылок, я просто хотел показать, что в популярных библиотеках, декораторы в классах более чем используются и они необязательно должны быть избыточностью.
Я не берусь, утверждать, что "декораторы отлично себя показывают в авторизации" но их присутствие например для проверки наличия прав у пользователя или проверки контекста запроса на то, является ли запрос анонимным или совершается авторизованным пользователем имеет место быть
Поверьте, я очень активно использую интерфейсы, и в любом случае, если вы хотите пользоваться преимуществами декораторов, и в то же время имеете множество реализаций для одного интерфейса, у вас всегда есть возможность либо написать функцию, которая будет принимать реализацию интерфейса и возвращать нужный вам декоратор либо вы можете описать базовый класс, от которого вы будете наследоваться вместе с интерфейсом, в котором будет описан тот или иной метод, позволяющий декорировать интересующие вас объекты той или иной логикой описанной в реализации вашего интерфейса
На моей практике использование декоратора на функции класса встречается с той же или даже с большей частотой чем на обычной функции, во всяком случае для многих питоновских библиотек это утверждение также будет верным.
Под более объемной логикой я имел в виду, что используя классы мне по-хорошему нужно будет описать интерфейсы, возможно описать какие-то базовые классы, описать реализации. А написав функцию я просто ее напишу в одном месте.
Опять же использование декораторов для авторизации и аутентификации по большей части предполагает наличие уже существующей части необходимого функционала в том или ином классе фреймворка, с которым вы работаете.
Если вы предполагаете написание всей авторизации с нуля. Я как и вы крайне бы НЕ рекомендовал описывать всю логику в декораторе
Декоратор в большей мере необходим для удобства использования какого-то фрагмента кода, но никак не для хранилища всей кодовой базы какой-либо фичи
Тут нет предвзятости, в плане того, что человек прошел курсы и на нем сразу стоит крест. Это конечно же недопустимо. Я в любом случае прочитаю остальную часть резюме, если там написано хоть что-то помимо курсов и оценю кандидата точно также как и любого другого но без раздела резюме, где упоминаются курсы
Сам я уже 5 лет пишу код и думаю, как и многих из вас, меня много раз спрашивали, с чего начать изучать программирование. Я всегда рассказываю, о том, какие языки программирования есть, какие задачи на каждом из них решаются, спрашиваю, что человеку было бы интересно делать самому и если их интересовал мой язык советовал порешать задачи из https://projecteuler.net/, советовал хотя бы обзорно почитать Лутца и пару книжек попроще, чтобы у людей сразу сложилось понимание о том, с чем они имеют дело, давал ссылки на различные обучающие ролики. Советовал, я, конечно, ровно то же, с чего начинал я, исключив только то, что оказалось в дальнейшем не нужным.
Я никогда не советовал курсы, так как, когда я лично еще 5 лет назад просматривал их материалы (которые периодически сливаются в сеть) я заметил, что курс на год или на 2 если постараться вполне себе можно освоить самостоятельно за более короткое время (буквально пару месяцев, или пол года в зависимости от вашего уровня занятости) и мне обидно, что начинающих разработчиков держат кучу времени на, на мой взгляд, уж очень растянутом материале. Люди тратят год или два своей жизни, их толком ничему не научили, а они даже еще не успели понять, что они в действительности будут делать.
Большинство моих знакомых, которых я лично считаю достаточно квалифицированными разработчиками, не проходили курсы и зачастую не учились на профильных специальностей.
Я понимаю, что многим людям в разы проще изучать что-то, когда им порционно выдают немного материала, какие-то небольшие домашние задания и в принципе говорят, что делать.
Но лично я испытываю искреннюю радость, когда вижу человека, у которого горят глаза, которому всего мало и он хочет здесь и сейчас узнать что-то новое, без чьей либо подачки пишет код просто для себя, просто потому что ему это нравится.
В совсем небольших проектах, я бы скорее использовал декоратор, для решения конкретно этой задачи, вместо того, чтобы писать объемную логику иначе. Но опять же, целесообразность применения того или иного паттерна для решения какой либо задачи чаще всего лежит на плечах самого разработчика или того, кто проверяет его код.
Я не могу гарантированно сказать, что применение декоратора в этом кейсе лучший вариант, так как это в равной мере зависит и от того, кто дает оценку и от того, какую цель мы преследуем (например написать быстро, качественно, или возможно нам нужна некоторая универсальность, возможно кто-то в принципе отказывается от написания классов, этого я знать не могу без контекста)
В том же djago, например есть возможность использовать вьюсеты как на базе классов, так и на базе функций, а fastapi по умолчанию работает с функциями
Я сам редко использую декораторы конкретно с этой целью, хоть я и работаю по большей части с django я обычно использую другие инструменты для проверки прав доступа, поэтому на руках хорошего примера не имею, добавлю в статью ссылку с примерами.
Про вложенные декораторы я писал, что это "экзотический пример", и в большинстве случаев его использования стоит избегать. Но местами это может быть удобно в применении (хоть сложность поддерживания увеличивается). Опять же такая конструкция должна быть чем-то оправдана, что в виду ее сложности бывает редко
На мой взгляд, важно, чтобы в большинстве случаев как раз таки не было необходимости проваливаться в код
Прошу прощения, если оскорбил кого-то своим комментарием. Такой цели я не преследовал. Я увидел некоторые комментарии, в которых авторы рассказывали о своих кейсах с поиском работы, мне, видимо ошибочно, казалось, что стоит рассказать и о своем опыте.
Прошу прощения, если оскорбил кого-то своим комментарием. Такой цели я не преследовал. Я увидел некоторые комментарии, в которых авторы рассказывали о своих кейсах с поиском работы, мне, видимо ошибочно, казалось, что стоит рассказать и о своем опыте.
Может кому-то будет интересно, но элемент последовательности Фибоначчи можно рассчитать намного быстрее
Рекомендую поизучать следующую библиотеку typer
Думаю, это поможет найти вдохновение на на вашу тему
Если вы используете класс, методы которого реализуют логику многих эндпоинтов, вам удобнее указать для каждого метода тот набор проверок, который вам необходим, одной из них может быть проверка, что пользователь авторизован, на какой-то ручке вы хотите проверить, что пользователь авторизован и имеет ту или иную роль, где-то вы хотите проверить какое либо значение из cookie, в данном случае вам удобнее всего повесить нужный набор декораторов на нужные вам методы. Альтернативой является наследование от какого-то другого класса и указание например общей для всех эндпоинтов проверки авторизации, что может не подходить для решения задачи, либо вам нужно иметь какой-то атрибут с маппингом, проверок, которые нужны для того или иного метода, что является менее явным. Либо вы можете написать для каждого эндпоинта свой класс, что делать дольше.
Если вы реализуете эндпоинты на базе функций, то вам всегда удобнее использовать декораторы
Я ссылался на статью про замыкание и в первом упоминании пространства имён я ссылаюсь на статью о нем. Возможно стоило раскрыть эту тему в одном из разделов статьи
Я не вижу противопоказаний к применению декораторов для проверок авторизации, особенно если у вас нет никакой сложной логики, или необходимости поддерживать множество вариантов авторизации для одного и того же эндпоинта, поэтому неудачным данный пример я все же назвать не могу
И потому что это удобный синтаксический сахар, который улучшает читаемость кода
И потому что, он полезен тем, что внутри декоратора есть свои уровни пространств имен, доступ к которым есть во вложенных в декоратор функциях, но это в любом случае свойство функций и сам синтаксический сахар тут не причем
Я предполагал, что читателям, не имеющим большого багажа опыта python разработки за спиной, может быть интересно, где чаще всего используется объект рассмотрения статьи, никакого более глубокого замысла не было. Думаю, что если бы статью писал другой человек, данный список возможно бы отличался, но по большей части наблюдалось бы пересечение элементов списка
Не вижу противоречий между, "применение имеет смысл" из статьи и "имеет место быть" из комментария выше
Под продвинутым использованием лично я подразумевал варианты и способы использования выходящие за рамки обзора большинства статей на аналогичную тему, что, на мой взгляд этим и является
По поводу приведения в пример потому что есть в библиотеке, не вижу тут ничего плохого, в плане того, что вы спокойно можете посмотреть реализацию в исходниках и при необходимости переделать под свои нужды
Опять же, в статье есть оглавление, в котором не указан подробный разбор конкретно этой темы.
Если это действительно важная тема требующая более детального рассмотрения, я с радостью освещу ее в одной из следующих статей
Что касается ссылок, я просто хотел показать, что в популярных библиотеках, декораторы в классах более чем используются и они необязательно должны быть избыточностью.
Я не берусь, утверждать, что "декораторы отлично себя показывают в авторизации" но их присутствие например для проверки наличия прав у пользователя или проверки контекста запроса на то, является ли запрос анонимным или совершается авторизованным пользователем имеет место быть
Поверьте, я очень активно использую интерфейсы, и в любом случае, если вы хотите пользоваться преимуществами декораторов, и в то же время имеете множество реализаций для одного интерфейса, у вас всегда есть возможность либо написать функцию, которая будет принимать реализацию интерфейса и возвращать нужный вам декоратор либо вы можете описать базовый класс, от которого вы будете наследоваться вместе с интерфейсом, в котором будет описан тот или иной метод, позволяющий декорировать интересующие вас объекты той или иной логикой описанной в реализации вашего интерфейса
тут пусто
Если код занимает 10-15 строк, то почему бы и нет, в обратном случае стоит подумать, действительно ли этому коду тут место
На моей практике использование декоратора на функции класса встречается с той же или даже с большей частотой чем на обычной функции, во всяком случае для многих питоновских библиотек это утверждение также будет верным.
Вот некоторые примеры
pydantic
django-rest-framework
Под более объемной логикой я имел в виду, что используя классы мне по-хорошему нужно будет описать интерфейсы, возможно описать какие-то базовые классы, описать реализации. А написав функцию я просто ее напишу в одном месте.
Опять же использование декораторов для авторизации и аутентификации по большей части предполагает наличие уже существующей части необходимого функционала в том или ином классе фреймворка, с которым вы работаете.
Если вы предполагаете написание всей авторизации с нуля. Я как и вы крайне бы НЕ рекомендовал описывать всю логику в декораторе
Декоратор в большей мере необходим для удобства использования какого-то фрагмента кода, но никак не для хранилища всей кодовой базы какой-либо фичи
Тут нет предвзятости, в плане того, что человек прошел курсы и на нем сразу стоит крест. Это конечно же недопустимо. Я в любом случае прочитаю остальную часть резюме, если там написано хоть что-то помимо курсов и оценю кандидата точно также как и любого другого но без раздела резюме, где упоминаются курсы
Сам я уже 5 лет пишу код и думаю, как и многих из вас, меня много раз спрашивали, с чего начать изучать программирование. Я всегда рассказываю, о том, какие языки программирования есть, какие задачи на каждом из них решаются, спрашиваю, что человеку было бы интересно делать самому и если их интересовал мой язык советовал порешать задачи из https://projecteuler.net/, советовал хотя бы обзорно почитать Лутца и пару книжек попроще, чтобы у людей сразу сложилось понимание о том, с чем они имеют дело, давал ссылки на различные обучающие ролики. Советовал, я, конечно, ровно то же, с чего начинал я, исключив только то, что оказалось в дальнейшем не нужным.
Я никогда не советовал курсы, так как, когда я лично еще 5 лет назад просматривал их материалы (которые периодически сливаются в сеть) я заметил, что курс на год или на 2 если постараться вполне себе можно освоить самостоятельно за более короткое время (буквально пару месяцев, или пол года в зависимости от вашего уровня занятости) и мне обидно, что начинающих разработчиков держат кучу времени на, на мой взгляд, уж очень растянутом материале. Люди тратят год или два своей жизни, их толком ничему не научили, а они даже еще не успели понять, что они в действительности будут делать.
Большинство моих знакомых, которых я лично считаю достаточно квалифицированными разработчиками, не проходили курсы и зачастую не учились на профильных специальностей.
Я понимаю, что многим людям в разы проще изучать что-то, когда им порционно выдают немного материала, какие-то небольшие домашние задания и в принципе говорят, что делать.
Но лично я испытываю искреннюю радость, когда вижу человека, у которого горят глаза, которому всего мало и он хочет здесь и сейчас узнать что-то новое, без чьей либо подачки пишет код просто для себя, просто потому что ему это нравится.
В совсем небольших проектах, я бы скорее использовал декоратор, для решения конкретно этой задачи, вместо того, чтобы писать объемную логику иначе. Но опять же, целесообразность применения того или иного паттерна для решения какой либо задачи чаще всего лежит на плечах самого разработчика или того, кто проверяет его код.
Я не могу гарантированно сказать, что применение декоратора в этом кейсе лучший вариант, так как это в равной мере зависит и от того, кто дает оценку и от того, какую цель мы преследуем (например написать быстро, качественно, или возможно нам нужна некоторая универсальность, возможно кто-то в принципе отказывается от написания классов, этого я знать не могу без контекста)
В том же djago, например есть возможность использовать вьюсеты как на базе классов, так и на базе функций, а fastapi по умолчанию работает с функциями
Я сам редко использую декораторы конкретно с этой целью, хоть я и работаю по большей части с django я обычно использую другие инструменты для проверки прав доступа, поэтому на руках хорошего примера не имею, добавлю в статью ссылку с примерами.
Про вложенные декораторы я писал, что это "экзотический пример", и в большинстве случаев его использования стоит избегать. Но местами это может быть удобно в применении (хоть сложность поддерживания увеличивается). Опять же такая конструкция должна быть чем-то оправдана, что в виду ее сложности бывает редко
На мой взгляд, важно, чтобы в большинстве случаев как раз таки не было необходимости проваливаться в код
Прошу прощения, если оскорбил кого-то своим комментарием. Такой цели я не преследовал. Я увидел некоторые комментарии, в которых авторы рассказывали о своих кейсах с поиском работы, мне, видимо ошибочно, казалось, что стоит рассказать и о своем опыте.
Прошу прощения, если оскорбил кого-то своим комментарием. Такой цели я не преследовал. Я увидел некоторые комментарии, в которых авторы рассказывали о своих кейсах с поиском работы, мне, видимо ошибочно, казалось, что стоит рассказать и о своем опыте.