Идея для контента очень интересная. С удовольствием подобное бы смотрел. Поставил на паузу, решил примерно за 45 минут. Выложил на гитхаб (но коммент с ссылкой был удален). Сейчас смотрю как задачу решил автор :)
Тоже поставил на паузу.. Решал несколько часов) За два подхода, ночами. Решил, теперь боюсь смотреть и на свой код, и продолжение видео. upd: гитхаб.ком /trinitatis/test_case_by_Pomidor
Хах. Нормально! Главное что получилось! Я думаю что это задача не на красоту кода, и не на то чтобы разгадать какую-то тайную схему абстракций. Просто такая , какая есть)
@@SeniorPomidorDeveloper Я, кажется, тоже потерял свой комментарий, на котрый Вы уже ответили: сначала он был, а позже я отредактировал его, хотел вставить ссылку на гитхаб, но не напрямую, а на русском, через пробелы, чтобы не выглядело как ссылка. Но, ИсКин Ютуба раскусил меня - удалили весь коммент целиком)) Ну да ладно.
Вот потому и не позвонили, видимо :) Кроме того, что код должен работать, он ещё и должен быть адекватно структурирован. Ну правда, у Вас isFirst определяется в дереве наследования не на том же уровне, на котором возникает сам класс First :) То же самое и с Second. Но методы isFirst и isSecond нельзя реализовывать в самих классах First и Second, так как это породит сильное зацепление двух классов, которые знать друг о друге ничего не должны. Однако принципы SOLID запрещают определить поведение в Parent, а потом First и Second сделать его потомками и там изменить поведение. Из этого делаем вывод, что Parent, First и Second не связаны родством, а являются классами одного уровня абстракции. При этом First и Second - это классы-состояния, а Parent поставляет интерфейс определения этого состояния. Потому решено: A и B должны иметь множественное наследование Parent+First и Parent+Second, при этом Parent должен поставлять методы isFirst и isSecond, которые проверяют self на isinstance соответствующего класса. Возможно авторы теста предполагали что-то другое, но я только такую структуру вижу адекватной, без лишних связей и с возможностью расширения.
Я бы ещё предложил методы из фёрст и из секонд перенести в классы Фёрст и Секонд (по названиям немного напрашивается), и я бы возможно ещё засунул в парент бульку из фёрст, и в конструкторах фёрста и секонда устанавливал её либо в тру либо в фалс, и в методах проверки превращал бы это в инт. Это уберёт магические числа из методов, и должно быть прозрачно для понимания потому что код находится в классах фёрст и секонд. И да, на падение тестов это не повлияет, но мы же понимаем что если тесты не пройдут код даже читать не будут, а вот если пройдут, то далее будут смотреть уже качество кода и навёрнутую архитектуру, а на сколько кандидат разгадал заложенные в тесты идеи. И в завершение вопрос, а щас подобная практика в найме встреречается, и если да то есть примеры актуальных заданий?
Тут уже несколько человек написали и каждый в этом задании увидел какую-то свою идею) это как в песнях Егора Летова ) А мне вот не кажется что тут была какая-то заложенная идея, которую кандидат должен разгадать. По моему , тут все очень просто. По поводу магических чисел и переменных в одну букву, они не плохи сами по себе. Плохо когда за ними скрываются какие-то осмысленные значения, смысл которых мы таким образом теряем. А к примеру, в математических функциях и задачках только магические числа и отдельные буквы и используют . По тому что изначально они не несут какого -то предметного смысла. И в этой задаче тоже очевидно что его нет. По поводу того, какие сейчас дают задания на собеседованиях, не могу сказать. Я их уже много лет не проходил. Я их сейчас провожу и даю там задание на разработку кое -какого мини-приложения.
@@SeniorPomidorDeveloper Ну так в этом же и смысл, докопаться до истины обсудить детали и разобрать всё по косточкам. А идеи имхо должны быть заложены, иначе зачем задание, просто проверить что человек понимает в наследование, знает что такое эксепшен и что существует декоратор проперти? Гораздо интересней посравнивать как люди интепретируют представленный пример TDD, какими архитектурными приёмами владеют (и именно владеют, а не просто знают, потому что тут это надо увидеть и применить, а не описать), имхо это самая ценная часть задание, и кстати если в конторе хорошо построена TDD, то задача может быть весьма близка в боевой работе, и она становится максимально релевантным заданием. Кстати понравилась идея с фабриками, и я бы даже предположил что А и Б это не классы, а просто функции возвращающие объекты Фёрст и Секонд, но их нейминг намекает на обратное, по этому наверно всё же нет.
@@TieoZ А если добавятся еще и Third b тд и вов сех них городить is{number} методы, учитывая что по заданию полагается что любой наследник паррента их реализует? Можно конечно это в паренте прописать, но это то же плохой дизайн поскольку из идеологии ООП полагается что родитель ничего не должен знать о наследниках. Тут миксин как высказался человек уже выше подходит лучше всего
@@mikeofs1304 Я исхожу из логики что инфу о том что в методах из Фёрст и из Секонд стоит опираться на некоторую общую бульку которая устанавливается для классов Фёрст и Секонд (и по этому само поле как общие данные мне хочется поднять в Парента и устанавливать при вызове супер конструктора). Кстати идея с третим класом натолкнула на мысль что это должна быть не булька, а инт. На счёт миксинов, не сразу понял как их сюда приложить, но пока писал это полотно, и обдумывал варианты, наконец понял что имелось в виду (да, с начала не понял, но мне можно, я не программист :Р) И вообще да, это выглядит логичнее, за одним нюансом, разве не является в таком случае проблемой то, что для проверки на инстанс этот миксин должен знать о всех наследниках на которые он должен проверять инстанс в методах?
Вы говорили, что есть у вас на Udemy курсы, думаю стоит ссылку на них оставить где-то в своем ютуб (в описании к видео или на странице сообщество). А то вдруг там есть что-то интересное, ведь ваши курсы на ютубе - огонь!
Случайно зашел на ваш канал. Очень понравилась идея решения тестовых заданий в видеороликах. Можете утешить мой интересен, ответив на вопрос: "Сколько у Вас лет практики в коммерческих проектах и какой стек технологий?"
Привет, расскажи пожалуйста про свой последний опыт поиска работы (за границей), что спрашивают?) Искал ли когда либо работу на американскую компанию (через посредника или самостоятельно)? Спасибо.
Да, работал и в Американских и в других заграничных компаниях, но очень давно работу не искал. Раньше просто на Хабр карьера и прочих Российских ресурсах находил такие вакансии. Сейчас надо как-то по-другому искать. Говорят что LinkedIn неплохо работает в этом смысле
Вообще конечно офигели. У меня как-то давно была начальница , которая попросила сделать тестовое дизайнера , мобильное приложение дизайн, потом не взяла ее на работу, а результат отдала iOS программисту , он немножко охренел от такого и уволился )
У меня для вас плохие новости :) За 10 лет вы так и не решили задачу :) 1. Очевидно что Parent - корень иерархии классов. 2. Если присмотреться к формулам, то очевидно, что обе формулы используют некое свойство (третий множитель), а значит это свойство общее для А и В, а значит это свойство (i) должно находится в Parent 3. Тогда у Parent должен быть конструктор с аргументом, который через наследование Second долетает до B. 4. Тогда конструктор А (без аргументов) - это перегруженый конструктор Parent с default значением. 5. Очевидно что А.func - это перегруженый метод B.func. А значит B.func должен находится в Parent, a A.func может перегружаться либо в А, либо в First 6. Очевидно что isFirst и isSecond - относятся к классам First и Second
@@SeniorPomidorDeveloper Но, скорее всего, вы специально наделали кучу ошибок, чтобы активности в комментариях побольше было. Как способ раскрутки канала и видео - я понимаю, но как ваш коллега сеньор разработчик - не одобряю.
Вы не сможете сделать Parent основой иерархии классов не нарушив принципы SOLID и не породив ненужного зацепления между First и Second. По крайней мере я не смог. И не смотря на то, что я у автора видео вижу тоже ну прям очевидные ошибки (как Вы и указали, например, что у него isFirst и isSecond это методы, которые явно появляются слишком поздно, когда First и Second классы давно существуют). Но всё же у Вас тоже ошибка в том, что Вы решили от Parent всё унаследовать, ну или я не вижу чего-то, что видите Вы, и потому у меня Parent в основании всё ломает, а Вы смогли как-то обойти эту проблему. Если да, поделитесь со мной, пожалуйста, как Вы это решили.
@@nikolaymatveychuk6145 Ну давайте разбираться. Из справки по isinstance: The isinstance() function checks if the object (first argument) is an instance or subclass of classinfo class (second argument). Ассерты в строчках 20 и 22, говорят нам что класс А является подклассом First и одновременно подклассом Parent. Множественного наследования нам не завезли, поэтому возможны два варианта. A extends First и First extends Parent, или A extends Parent и Parent extends First. Запомним эти варианты, посмотрим на такие же ассерты для B: В extends Second и Second extends Parent, или B extends Parent и Parent extends Second. Явно видно что вариант A extends Parent и Parent extends First и B extends Parent и Parent extends Second. Невозможен по причине отсутствия множественного наследования. У нас остаются три варианта: 1. A extends First и First extends Parent и B extends Parent и Parent extends Second 2. A extends Parent и Parent extends First и В extends Second и Second extends Parent 3. A extends First и First extends Parent и В extends Second и Second extends Parent Первый и второй варианты выглядят очень запутанными иерархиями, к тому же имя класса Parent, явно на что-то намекает :D
Ответ не принял бы, потому что у классов есть общее поведение, но оно не вынесено в родительские классы, а реализация не консистентная (в одном случае num, в другом - с, в одном случае через self обращаешься, в другом через имя класса. isFirst и isSecond очевидно должны быть вынесены в миксин и возвращать не 0 или 1 а True или False (должна быть проверка на isinstance в методе)
да , задание намекает на то, что испытуемый должен прежде всег овостановить ирархию классов и логику ее построения, в идеале видимо понять что эт овообще такое, а не просто зачекаться по ассертам. Например вероятнее всего i это какая то базовая характеристика сущности, и 3 ее значение поумолчанию, а иначе она инится явно в классе - том же B.Ну и как вы замечаете это должно быт ьв паренте
@@SeniorPomidorDeveloper хорошо завтранакидаю, а то в РФ ночь уже)) Сейчас кстати дошло что A и B это вообще не классы скорее всего, а фабрики. Потому что рефлексией проверяются не они
@@SeniorPomidorDeveloper По поводу сигнатуры абстракт метода можно и лучше сделать, она слишком широкая, но лень уже на него время тратить from abc import ABC, abstractmethod class MyError(Exception): """custom error""" class Parent(ABC): def __init__(self, i=3): self.i = i @abstractmethod def fnc (self, *args) -> int: """function for extending""" class First(Parent): def fnc(self, one: int) ->int: if one == 7: raise MyError("Error text") return one**2*self.i class Second(Parent): def fnc(self, one: int, two: int) ->int: return one*two*self.i class ClassChecker(): def isFirst(self) -> bool: return isinstance(self, First) @property def isSecond(self) -> bool: return isinstance(self, Second) class A(ClassChecker, First): """class A""" class B(ClassChecker, Second): """class B"""
Кстати вы переменную i в классе A как переменную класса объявили, что в общем то считается плохой практикой если вы не пометили ее как прайват, и в целом предполагаете использовать не для внутреней логики в инстансах, а и во внешних каких то операциях. По сути через A.i получается доступ ко всем i экземпляров этого класса , что может повлечь в случае ошибок применения(и использования вашего кода как библиотечного другими разарабами) очень слабопредсказуемое поведение. Тут как раз проперти подходит гораздо лучше, поскольку позволяет контролировать доступ
А я в моменте с AttributeError решил изменить логику переприсваивания атрибута, про @property не знал def __setattr__(self, name, value): if name == "isSecond" and value == 2: raise AttributeError super.__setattr__(self, name, value)
Было очень познавательно и интересно, спасибо! =)
проверки isFirst/isSecond лучше сделать через наследование от Parent
class Parent:
def isFirst(self):
return isinstance(self, First)
@property
def isSecond(self):
return isinstance(self, Second)
@isSecond.setter
def isSecond(self, value):
raise AttributeError
Огромное спасибо, мне как раз классы надо повторить было. Тут как раз вся база!
Идея для контента очень интересная. С удовольствием подобное бы смотрел.
Поставил на паузу, решил примерно за 45 минут. Выложил на гитхаб (но коммент с ссылкой был удален). Сейчас смотрю как задачу решил автор :)
Да, ютюб удаляет комментарии где ссылки .(
Тоже поставил на паузу.. Решал несколько часов) За два подхода, ночами. Решил, теперь боюсь смотреть и на свой код, и продолжение видео.
upd:
гитхаб.ком /trinitatis/test_case_by_Pomidor
Хах. Нормально! Главное что получилось! Я думаю что это задача не на красоту кода, и не на то чтобы разгадать какую-то тайную схему абстракций.
Просто такая , какая есть)
@@SeniorPomidorDeveloper Я, кажется, тоже потерял свой комментарий, на котрый Вы уже ответили: сначала он был, а позже я отредактировал его, хотел вставить ссылку на гитхаб, но не напрямую, а на русском, через пробелы, чтобы не выглядело как ссылка. Но, ИсКин Ютуба раскусил меня - удалили весь коммент целиком))
Ну да ладно.
@julesbois2122 хах. Бывает )
Интересное задание. Мне бы точно пришлось потратить на это несколько часов. А про property вряд ли бы вспомнил. Спасибо за контент
important tnks!
Вот потому и не позвонили, видимо :) Кроме того, что код должен работать, он ещё и должен быть адекватно структурирован. Ну правда, у Вас isFirst определяется в дереве наследования не на том же уровне, на котором возникает сам класс First :) То же самое и с Second. Но методы isFirst и isSecond нельзя реализовывать в самих классах First и Second, так как это породит сильное зацепление двух классов, которые знать друг о друге ничего не должны. Однако принципы SOLID запрещают определить поведение в Parent, а потом First и Second сделать его потомками и там изменить поведение. Из этого делаем вывод, что Parent, First и Second не связаны родством, а являются классами одного уровня абстракции. При этом First и Second - это классы-состояния, а Parent поставляет интерфейс определения этого состояния. Потому решено: A и B должны иметь множественное наследование Parent+First и Parent+Second, при этом Parent должен поставлять методы isFirst и isSecond, которые проверяют self на isinstance соответствующего класса. Возможно авторы теста предполагали что-то другое, но я только такую структуру вижу адекватной, без лишних связей и с возможностью расширения.
Да наверное я просто не понял это задание. Надеюсь что они сами его поняли. Надо уже их пригласить в студию, пусть расскажут наконец)
Я бы ещё предложил методы из фёрст и из секонд перенести в классы Фёрст и Секонд (по названиям немного напрашивается), и я бы возможно ещё засунул в парент бульку из фёрст, и в конструкторах фёрста и секонда устанавливал её либо в тру либо в фалс, и в методах проверки превращал бы это в инт.
Это уберёт магические числа из методов, и должно быть прозрачно для понимания потому что код находится в классах фёрст и секонд.
И да, на падение тестов это не повлияет, но мы же понимаем что если тесты не пройдут код даже читать не будут, а вот если пройдут, то далее будут смотреть уже качество кода и навёрнутую архитектуру, а на сколько кандидат разгадал заложенные в тесты идеи.
И в завершение вопрос, а щас подобная практика в найме встреречается, и если да то есть примеры актуальных заданий?
Тут уже несколько человек написали и каждый в этом задании увидел какую-то свою идею) это как в песнях Егора Летова ) А мне вот не кажется что тут была какая-то заложенная идея, которую кандидат должен разгадать. По моему , тут все очень просто.
По поводу магических чисел и переменных в одну букву, они не плохи сами по себе. Плохо когда за ними скрываются какие-то осмысленные значения, смысл которых мы таким образом теряем. А к примеру, в математических функциях и задачках только магические числа и отдельные буквы и используют . По тому что изначально они не несут какого -то предметного смысла. И в этой задаче тоже очевидно что его нет.
По поводу того, какие сейчас дают задания на собеседованиях, не могу сказать. Я их уже много лет не проходил. Я их сейчас провожу и даю там задание на разработку кое -какого мини-приложения.
@@SeniorPomidorDeveloper Ну так в этом же и смысл, докопаться до истины обсудить детали и разобрать всё по косточкам.
А идеи имхо должны быть заложены, иначе зачем задание, просто проверить что человек понимает в наследование, знает что такое эксепшен и что существует декоратор проперти? Гораздо интересней посравнивать как люди интепретируют представленный пример TDD, какими архитектурными приёмами владеют (и именно владеют, а не просто знают, потому что тут это надо увидеть и применить, а не описать), имхо это самая ценная часть задание, и кстати если в конторе хорошо построена TDD, то задача может быть весьма близка в боевой работе, и она становится максимально релевантным заданием.
Кстати понравилась идея с фабриками, и я бы даже предположил что А и Б это не классы, а просто функции возвращающие объекты Фёрст и Секонд, но их нейминг намекает на обратное, по этому наверно всё же нет.
@@TieoZ А если добавятся еще и Third b тд и вов сех них городить is{number} методы, учитывая что по заданию полагается что любой наследник паррента их реализует? Можно конечно это в паренте прописать, но это то же плохой дизайн поскольку из идеологии ООП полагается что родитель ничего не должен знать о наследниках. Тут миксин как высказался человек уже выше подходит лучше всего
@@mikeofs1304 Я исхожу из логики что инфу о том что в методах из Фёрст и из Секонд стоит опираться на некоторую общую бульку которая устанавливается для классов Фёрст и Секонд (и по этому само поле как общие данные мне хочется поднять в Парента и устанавливать при вызове супер конструктора). Кстати идея с третим класом натолкнула на мысль что это должна быть не булька, а инт.
На счёт миксинов, не сразу понял как их сюда приложить, но пока писал это полотно, и обдумывал варианты, наконец понял что имелось в виду (да, с начала не понял, но мне можно, я не программист :Р) И вообще да, это выглядит логичнее, за одним нюансом, разве не является в таком случае проблемой то, что для проверки на инстанс этот миксин должен знать о всех наследниках на которые он должен проверять инстанс в методах?
Вы столько написали интересных идей, что теперь просто обязаны предоставить свои варианты 😀
Интересно
Вы говорили, что есть у вас на Udemy курсы, думаю стоит ссылку на них оставить где-то в своем ютуб (в описании к видео или на странице сообщество). А то вдруг там есть что-то интересное, ведь ваши курсы на ютубе - огонь!
Да пока так ничего и не получилось снять для Udemy ( делал один курс, но не доделал
Случайно зашел на ваш канал. Очень понравилась идея решения тестовых заданий в видеороликах. Можете утешить мой интересен, ответив на вопрос: "Сколько у Вас лет практики в коммерческих проектах и какой стек технологий?"
Да лет 10 на Джанге )
Привет, расскажи пожалуйста про свой последний опыт поиска работы (за границей), что спрашивают?) Искал ли когда либо работу на американскую компанию (через посредника или самостоятельно)? Спасибо.
Да, работал и в Американских и в других заграничных компаниях, но очень давно работу не искал. Раньше просто на Хабр карьера и прочих Российских ресурсах находил такие вакансии. Сейчас надо как-то по-другому искать. Говорят что LinkedIn неплохо работает в этом смысле
Выложите курс и на степик пожалуйста. Люди из РФ не смогут на юдеми их купить
Так все курсы на Ютюбе )
👍
Эх какие простые задания были…
Сейчас просят сайт создать на джанго, с бд и логикой, и прочим.. короче задание на недельку) и это на интерна..
😄
Для сайта на Джанго есть курс )
еще платежку прикрутить, админку закастомизировать, завернуть в докер
и да, такое тестовое не оплачивается
@@Griboriи таких контор пруд пруди.
Вообще конечно офигели. У меня как-то давно была начальница , которая попросила сделать тестовое дизайнера , мобильное приложение дизайн, потом не взяла ее на работу, а результат отдала iOS программисту , он немножко охренел от такого и уволился )
У меня для вас плохие новости :) За 10 лет вы так и не решили задачу :)
1. Очевидно что Parent - корень иерархии классов.
2. Если присмотреться к формулам, то очевидно, что обе формулы используют некое свойство (третий множитель), а значит это свойство общее для А и В, а значит это свойство (i) должно находится в Parent
3. Тогда у Parent должен быть конструктор с аргументом, который через наследование Second долетает до B.
4. Тогда конструктор А (без аргументов) - это перегруженый конструктор Parent с default значением.
5. Очевидно что А.func - это перегруженый метод B.func. А значит B.func должен находится в Parent, a A.func может перегружаться либо в А, либо в First
6. Очевидно что isFirst и isSecond - относятся к классам First и Second
😭
@@SeniorPomidorDeveloper Но, скорее всего, вы специально наделали кучу ошибок, чтобы активности в комментариях побольше было. Как способ раскрутки канала и видео - я понимаю, но как ваш коллега сеньор разработчик - не одобряю.
🤣
Вы не сможете сделать Parent основой иерархии классов не нарушив принципы SOLID и не породив ненужного зацепления между First и Second. По крайней мере я не смог. И не смотря на то, что я у автора видео вижу тоже ну прям очевидные ошибки (как Вы и указали, например, что у него isFirst и isSecond это методы, которые явно появляются слишком поздно, когда First и Second классы давно существуют). Но всё же у Вас тоже ошибка в том, что Вы решили от Parent всё унаследовать, ну или я не вижу чего-то, что видите Вы, и потому у меня Parent в основании всё ломает, а Вы смогли как-то обойти эту проблему. Если да, поделитесь со мной, пожалуйста, как Вы это решили.
@@nikolaymatveychuk6145 Ну давайте разбираться.
Из справки по isinstance:
The isinstance() function checks if the object (first argument) is an instance or subclass of classinfo class (second argument).
Ассерты в строчках 20 и 22, говорят нам что класс А является подклассом First и одновременно подклассом Parent. Множественного наследования нам не завезли, поэтому возможны два варианта. A extends First и First extends Parent, или A extends Parent и Parent extends First.
Запомним эти варианты, посмотрим на такие же ассерты для B: В extends Second и Second extends Parent, или B extends Parent и Parent extends Second.
Явно видно что вариант A extends Parent и Parent extends First и B extends Parent и Parent extends Second. Невозможен по причине отсутствия множественного наследования.
У нас остаются три варианта:
1. A extends First и First extends Parent и B extends Parent и Parent extends Second
2. A extends Parent и Parent extends First и В extends Second и Second extends Parent
3. A extends First и First extends Parent и В extends Second и Second extends Parent
Первый и второй варианты выглядят очень запутанными иерархиями, к тому же имя класса Parent, явно на что-то намекает :D
микросервисные монолиты скоро покажешь как делать?)
Я только монолитные микросервисы умею )
@@SeniorPomidorDeveloper покажешь как умеешь мы посомтрим :D
Ответ не принял бы, потому что у классов есть общее поведение, но оно не вынесено в родительские классы, а реализация не консистентная (в одном случае num, в другом - с, в одном случае через self обращаешься, в другом через имя класса. isFirst и isSecond очевидно должны быть вынесены в миксин и возвращать не 0 или 1 а True или False (должна быть проверка на isinstance в методе)
assert(0) я бы тоже поправил на assert 0
да , задание намекает на то, что испытуемый должен прежде всег овостановить ирархию классов и логику ее построения, в идеале видимо понять что эт овообще такое, а не просто зачекаться по ассертам. Например вероятнее всего i это какая то базовая характеристика сущности, и 3 ее значение поумолчанию, а иначе она инится явно в классе - том же B.Ну и как вы замечаете это должно быт ьв паренте
@mikeofs1304 присылайте варианты. Интересно, какая это могла бы быть иерархия классов.
@@SeniorPomidorDeveloper хорошо завтранакидаю, а то в РФ ночь уже)) Сейчас кстати дошло что A и B это вообще не классы скорее всего, а фабрики. Потому что рефлексией проверяются не они
@@SeniorPomidorDeveloper По поводу сигнатуры абстракт метода можно и лучше сделать, она слишком широкая, но лень уже на него время тратить
from abc import ABC, abstractmethod
class MyError(Exception):
"""custom error"""
class Parent(ABC):
def __init__(self, i=3):
self.i = i
@abstractmethod
def fnc (self, *args) -> int:
"""function for extending"""
class First(Parent):
def fnc(self, one: int) ->int:
if one == 7:
raise MyError("Error text")
return one**2*self.i
class Second(Parent):
def fnc(self, one: int, two: int) ->int:
return one*two*self.i
class ClassChecker():
def isFirst(self) -> bool:
return isinstance(self, First)
@property
def isSecond(self) -> bool:
return isinstance(self, Second)
class A(ClassChecker, First):
"""class A"""
class B(ClassChecker, Second):
"""class B"""
Кстати вы переменную i в классе A как переменную класса объявили, что в общем то считается плохой практикой если вы не пометили ее как прайват, и в целом предполагаете использовать не для внутреней логики в инстансах, а и во внешних каких то операциях. По сути через A.i получается доступ ко всем i экземпляров этого класса , что может повлечь в случае ошибок применения(и использования вашего кода как библиотечного другими разарабами) очень слабопредсказуемое поведение. Тут как раз проперти подходит гораздо лучше, поскольку позволяет контролировать доступ
Это не плохая практика, это дефолтное значение, плохая практика это менять A.i
@@clauseclause6640 плохая практика A._i менять
Вітаю, добра тобі! Як ти дивишся на те щоби зняти пару роликів про сесії в Джанго? Типу що з ними робити( корзина, аутентифікація і тд) Дякую
Дякую !
Про сессии может получится в будущих курсах сделать
@@SeniorPomidorDeveloper Thanks, your courses are the best!
Бредозадание , джун какойто придумал
согл
+
Гарри Дюбуа это вы?
пока нет
@@SeniorPomidorDeveloper спасибо за курсы!
А я в моменте с AttributeError решил изменить логику переприсваивания атрибута, про @property не знал
def __setattr__(self, name, value):
if name == "isSecond" and value == 2:
raise AttributeError
super.__setattr__(self, name, value)
Наверное хардкодить имя метода в setattr это не очень гибкое решение. А вцелом да, вполне подходит
Вы после super скобочки забыли))
@@igorratnik2357 Действительно, как-то прошляпил