(Немного могу подушить, но статья и правда похожа на "разбор" декораторов, ка будто _без глубокого изучения материала_)
(Писал с телефона, за форматмрование извините)
(Мне не нравится эта статья. Это же перевод? Что ж, переводчик тоже должен быть способен отбирать информацию, а не переводить всё подряд)
Список фейлов в "статье":
"С учетом нашего изначального определения декоратора..."
Приведено не определение, а пример использования, на крайний случай это объяснение способа работы (что делает), а не определение (чем является) декоратора.
"В итоге мы обрабатываем три функции..."
Где обрабатываете? В приведённом фрагменте кода присутствуют имена (retry, _wrapper, might_fail), они максимум используются
"Декоратор – не что иное, как функция (которая принимает другую функцию в качестве аргумента)"
Смешно, но больше, пожалуйста, так не шутите в статьях на подобную тему.
(придирка):
"Чтобы использовать декоратор, нужно поместить его перед определением функции без ее вызова"
Больше на заметку похоже, слишком поверхностно ("оно подходит под то, что мы придумали, значит это оно и есть").
(придирка):
Не используйте "except:" (bare except) — это опасно, так как в этом случае ловятся _больше, чем все_ ошибки и в приведённом примере можно было указать, какие ошибки перехватывать и подавлять.
"В частности, он меняет некоторые атрибуты специальных методов...",
"При использовании @functools.wraps все эти атрибуты возвращаются к значениям по умолчанию."
Опять же: не шутите так больше, если не знаете, о чём пишете: functools.wraps ничего не "возвращает к значениям по умолчанию", а копирует метаданные переданного (объекта?) (у вас это функция func) на оборачиваемый (объект? функцию? пусть будет так)
" Этот факт никак не меняет логику или функциональность нашего декоратора-таймера. С таким же успехом вы могли бы вообще не использовать @functools.wraps."
Ну так и не используйте — абзац не несёт полезной нагрузки: сказали "мы используем это, а что это такое — не важно, можете не использовать", тема не раскрыта.
"Помните, что @нотация - это просто эквивалент записи MyClass = timer(MyClass), т.е. декоратор будет вызван только тогда, когда вы «вызовете» класс"
Так разве это не означает, что декоратор будет вызван тогда, когда будет созаваться сам класс, а не объект этого класса? Здесь, насколько мне стало понятно из pep 3129, декоратором является это:
"@timer
class MyClass: ..."
"Методы класса не декорируются автоматически при декорации класса. Проще говоря, при использовании декоратора для обычного класса декорируется только его конструктор (метод __init__)."
Хотел опять пошутить "не шутите так больше", но кстал от полного непонимания темы в статье. КАК МОЖНО В ДВУХ СОСЕДНИХ ПРЕДЛОЖЕНИЯХ СКАЗАТЬ СОВЕРШЕННО РАЗНЫЕ И НЕ СЛЕДУЮЩИЕ ДРУГ ИЗ ДРУГА ВЕЩИ? Только что же вроде правильно написали, что декорируется **класс**. Так почему в следующем какой-то абсурдный вывод? (Хабровчане, научите зарабатывать социальный рейтинг на миска риса чтобы ставить отметка на плохой статья).
"Декорирование класса в Python работает как изменение класса извне (т.е. из декоратора)."
Опять же, несколькими предложениями назад было чётко написано, что декорирование = вызов декоратора на декорируемом объекте, так почему тут вывод, (не совсем совершенно, но в целом) не следующий из выше написанного? Если декорирование это вызов декоратора на декорируемом объекте (функция/класс), то это означает, что внутри с переданным можно делать то же, что и без декоратора - что-то, что и так разрешено делать с функциями или классами извне (в случае наслоения декораторов - **на результате вызова предыдущего декоратора**).
"Вы можете использовать декораторы для изменения классов подобно наследованию."
Выше уже писал в общем виде, здесь конкретизирую: наследование и декорирование - разные вещи. Они **НЕ** подобны.
(придирка):
"Декоратор dataclass из стандартной библиотеки - отличный пример разумного использования, при котором декораторы предпочтительнее наследования"
Обычно декоратор dataclass используется для dto'шек (классы данных) + какой-то дополнительной логики. В основном он используется (как сам встречал) для уменьшения однотипного _boilerplate_ кода.
"Отсюда можно сделать два вывода:
Декораторы могут быть вложенными. Важен порядок их написания.
Декоратор @dataclass_json добавил в наш класс метод to_dict"
На второе утверждение мне в целом всё равно, интересует только первое: Этот абзаз (или эти абзацы), насколько понятно из них самих, показывают примеры использования некоторых готовых декораторов. Эти предложения, в свою очередь, имеют отношение к разбору использования декораторов в целом. Считаю, что статья не структурирована (к примеру, мне не интересно читать про готовые декораторы и я хочу пропусить часть статьи, где приводятся примеры, но непосредственно в этой части нагло спрятана основная часть стати, которая мне могла бы быть потенциально интересна и может даже полезна)
"Завтра в **** состоится открытое занятие «Docker ..."
И вся эта "с т а т ь я" была лишь для рекламы курсов. По качеству этой статьи даже посещать всякие "занятия" не привлекает вообще. Реклама так себе.
P. S. я найти способ понять социальный рейтинг — надо написать хороший статья про декораторы.
так сам смысл в том, чтобы иметь бумажный вариант в случае недоступности телефона, но с ручным перерисовыванием, конечно, стало интереснее, но сложнее.
Comparator.comparing требует либо ToIntFunction (что происходит при String::length), либо Function с возвратом чего-то сравнимого: <T, U extends Comparable<U>>comparing(Function<? super T, ? extends U> keyExtractor)
Как понятно из String::toLowerCase, он возвращает String, который, кажется, не является Comparable
Так что здесь никакой магии нет, просто так и не должно быть.
да, давно существует такое ограничение. и оно оправдано: чем старше человек, тем богаче жизненный опыт. а дискриминация по полу не разумна на подобных мероприятиях, так как пол здесь не главный признак.
Научиться не перебивать собеседника — действительно важная составляющая разговора, но в вашей статье нет ни слова про то, "как" же это сделать.
https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.filter.html
https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.applymap.html
это подходит вместо for?
"Скобки" принято называть "периодом", если правильно помню
при этом всё посыпется при первой попытке добавить внешний "CarElement", например, новый тип двигателя
(Немного могу подушить, но статья и правда похожа на "разбор" декораторов, ка будто _без глубокого изучения материала_)
(Писал с телефона, за форматмрование извините)
(Мне не нравится эта статья. Это же перевод? Что ж, переводчик тоже должен быть способен отбирать информацию, а не переводить всё подряд)
Список фейлов в "статье":
"С учетом нашего изначального определения декоратора..."
Приведено не определение, а пример использования, на крайний случай это объяснение способа работы (что делает), а не определение (чем является) декоратора.
"В итоге мы обрабатываем три функции..."
Где обрабатываете? В приведённом фрагменте кода присутствуют имена (retry, _wrapper, might_fail), они максимум используются
"Декоратор – не что иное, как функция (которая принимает другую функцию в качестве аргумента)"
Смешно, но больше, пожалуйста, так не шутите в статьях на подобную тему.
(придирка):
"Чтобы использовать декоратор, нужно поместить его перед определением функции без ее вызова"
Больше на заметку похоже, слишком поверхностно ("оно подходит под то, что мы придумали, значит это оно и есть").
(придирка):
Не используйте "except:" (bare except) — это опасно, так как в этом случае ловятся _больше, чем все_ ошибки и в приведённом примере можно было указать, какие ошибки перехватывать и подавлять.
"В частности, он меняет некоторые атрибуты специальных методов...",
"При использовании @functools.wraps все эти атрибуты возвращаются к значениям по умолчанию."
Опять же: не шутите так больше, если не знаете, о чём пишете: functools.wraps ничего не "возвращает к значениям по умолчанию", а копирует метаданные переданного (объекта?) (у вас это функция func) на оборачиваемый (объект? функцию? пусть будет так)
" Этот факт никак не меняет логику или функциональность нашего декоратора-таймера. С таким же успехом вы могли бы вообще не использовать @functools.wraps."
Ну так и не используйте — абзац не несёт полезной нагрузки: сказали "мы используем это, а что это такое — не важно, можете не использовать", тема не раскрыта.
"Помните, что @нотация - это просто эквивалент записи MyClass = timer(MyClass), т.е. декоратор будет вызван только тогда, когда вы «вызовете» класс"
Так разве это не означает, что декоратор будет вызван тогда, когда будет созаваться сам класс, а не объект этого класса? Здесь, насколько мне стало понятно из pep 3129, декоратором является это:
"@timer
class MyClass: ..."
"Методы класса не декорируются автоматически при декорации класса. Проще говоря, при использовании декоратора для обычного класса декорируется только его конструктор (метод __init__)."
Хотел опять пошутить "не шутите так больше", но кстал от полного непонимания темы в статье. КАК МОЖНО В ДВУХ СОСЕДНИХ ПРЕДЛОЖЕНИЯХ СКАЗАТЬ СОВЕРШЕННО РАЗНЫЕ И НЕ СЛЕДУЮЩИЕ ДРУГ ИЗ ДРУГА ВЕЩИ? Только что же вроде правильно написали, что декорируется **класс**. Так почему в следующем какой-то абсурдный вывод? (Хабровчане, научите зарабатывать социальный рейтинг на миска риса чтобы ставить отметка на плохой статья).
"Декорирование класса в Python работает как изменение класса извне (т.е. из декоратора)."
Опять же, несколькими предложениями назад было чётко написано, что декорирование = вызов декоратора на декорируемом объекте, так почему тут вывод, (не совсем совершенно, но в целом) не следующий из выше написанного? Если декорирование это вызов декоратора на декорируемом объекте (функция/класс), то это означает, что внутри с переданным можно делать то же, что и без декоратора - что-то, что и так разрешено делать с функциями или классами извне (в случае наслоения декораторов - **на результате вызова предыдущего декоратора**).
"Вы можете использовать декораторы для изменения классов подобно наследованию."
Выше уже писал в общем виде, здесь конкретизирую: наследование и декорирование - разные вещи. Они **НЕ** подобны.
(придирка):
"Декоратор dataclass из стандартной библиотеки - отличный пример разумного использования, при котором декораторы предпочтительнее наследования"
Обычно декоратор dataclass используется для dto'шек (классы данных) + какой-то дополнительной логики. В основном он используется (как сам встречал) для уменьшения однотипного _boilerplate_ кода.
"Отсюда можно сделать два вывода:
Декораторы могут быть вложенными. Важен порядок их написания.
Декоратор @dataclass_json добавил в наш класс метод to_dict"
На второе утверждение мне в целом всё равно, интересует только первое: Этот абзаз (или эти абзацы), насколько понятно из них самих, показывают примеры использования некоторых готовых декораторов. Эти предложения, в свою очередь, имеют отношение к разбору использования декораторов в целом. Считаю, что статья не структурирована (к примеру, мне не интересно читать про готовые декораторы и я хочу пропусить часть статьи, где приводятся примеры, но непосредственно в этой части нагло спрятана основная часть стати, которая мне могла бы быть потенциально интересна и может даже полезна)
"Завтра в **** состоится открытое занятие «Docker ..."
И вся эта "с т а т ь я" была лишь для рекламы курсов. По качеству этой статьи даже посещать всякие "занятия" не привлекает вообще. Реклама так себе.
P. S. я найти способ понять социальный рейтинг — надо написать хороший статья про декораторы.
Пожалуйста, не пишите слишком много сокращений в статье ("оч", "след", ...). Это сильно режет глаза
А бывали случаи, когда человека останавливали уже после удачного самоубийства?
Спасибо. Читал на уроке литературы.
Выше написали про это, но я добавлю:
И так, чтобы не писать boilerplate:
в 3 ночи вспоминаю, что завтра так-то ещё среда
Иллюзия выбора
А в какой стране, мы с вами никогда не узнаем)
после этого я засомневался в способностях автора.
Что дальше, делать вместо одного объекта кучу "полей" по типу "file_name", "file_type", "file_path", "file_open_mode" вместо "file" со всем внутри?
необязательно использовать генератор списков и сразу распаковывать – можно и обычный генератор в скобки обернуть
Жду продолжения
так сам смысл в том, чтобы иметь бумажный вариант в случае недоступности телефона, но с ручным перерисовыванием, конечно, стало интереснее, но сложнее.
Comparator.comparingтребует либоToIntFunction(что происходит приString::length), либоFunctionс возвратом чего-то сравнимого:<T, U extends Comparable<U>>comparing(Function<? super T, ? extends U> keyExtractor)Как понятно из
String::toLowerCase, он возвращаетString, который, кажется, не являетсяComparableТак что здесь никакой магии нет, просто так и не должно быть.
да, давно существует такое ограничение. и оно оправдано: чем старше человек, тем богаче жизненный опыт. а дискриминация по полу не разумна на подобных мероприятиях, так как пол здесь не главный признак.
□□□ □□□ □□□□□□□□, □ □□ □□□□ □□□□□□□□□. □□□□□□□□□!