Ответ на задачу выше. 🔍

Проблема в том, что все экземпляры Bus, конструктору которых не был явно передан список пассажиров, разделяют один и тот же список по умолчанию.

Это тонкая ошибка. Из примера видно, что когда объект Bus инициализируется списком пассажиров, он работает правильно. ✅

Странности начинаются, когда Bus вначале пуст, потому что в этом случае self.passengers оказывается псевдонимом значения по умолчанию для параметра passengers.

Беда в том, что любое значение по умолчанию вычисляется в момент определения функции, т. е. обычно на этапе загрузки модуля, после чего значения по умолчанию становятся атрибутами объекта-функции.

Так что если значение по умолчанию – изменяемый объект и вы его изменили, то изменение отразится и на всех последующих вызовах функции. ⚠️

Если после выполнения кода из примера проинспектировать объект Bus.__init__, то мы обнаружим имена в его атрибуте __defaults__:

dir(Bus.__init__)
# ['__annotations__', '__call__', ..., '__defaults__', ...]  


Bus.__init__.__defaults__
# (['Vasiliy', 'Julia'],)  

Наконец, можно убедиться, что bus2.passengers – псевдоним первого элемента атрибута:

Bus.__init__.__defaults__[0] is bus2.passengers  # True

Описанная проблема и есть причина того, почему для параметров, принимающих изменяемые значения, часто по умолчанию задается значение None. ❗️
Например:

class Bus:  
    def __init__(self, passengers=None):
        if passengers is None:
            # Создаем новый пустой список 
            self.passengers = []  
        else:
            # Связываем копию  
            self.passengers = list(passengers)  

В примере init проверяет, верно ли, что аргумент passengers совпадает с None, и, если это так, присваивает атрибуту self.passengers вновь созданный пустой список. Если passengers не совпадает с None, то правильное решение заключается в том, чтобы связать копию этого атрибута с self.passengers.

Но при написании функции, принимающей изменяемый параметр, нужно тщательно обдумать, ожидает ли вызывающая сторона, что переданный аргумент может быть изменен. 🤔
——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Стандартная метафора «переменные – это ящики» ведет к непониманию ссылочных переменных в объектно-ориентированных языках.

Переменные в Python похожи на ссылочные переменные, поэтому лучше представлять их как этикетки, приклеенные к объектам.

Следующий пример поможет понять, почему.

>>> a = [1, 2, 3]
>>> b = a 
>>> a.append(4)
>>> b 
>>> [1, 2, 3, 4]

1. Создать список [1, 2, 3] и связать с ним переменную a
2. Связать переменную b с тем же значением, на которое ссылается a.
3. Изменить список, на который ссылается a, добавив в конец еще один элемент.
4. Можно наблюдать, как это отразилось на переменной b.
5. Если считать b ящиком, в котором хранилась копия списка [1, 2, 3] из ящика a, то такое поведение бессмысленно.

Таким образом, предложение b = a не копирует содержимое ящика a в ящик b, а наклеивает метку b на объект, уже имеющий метку a.

Для правильного понимания присваивания в Python всегда сначала читайте правую часть, ту, где объект создается или извлекается. Уже после этого переменная в левой части связывается с объектом – как приклеенная к нему этикетка. А о ящиках забудьте.

Поскольку переменные – это просто этикетки, ничто не мешает наклеить на объект несколько этикеток. В этом случае образуются псевдонимы.

Тем самым оператор is проверяет, что разные этикетки наклеены на один и тот же ящик.
А оператор == проверяет, что разные ящики имеют одинаковое содержимое.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

✨ Принцип DRY (Don't Repeat Yourself)

Это один из основных принципов программирования, который утверждает, что "не следует повторять себя". Он призывает избегать дублирования кода и данных, что помогает упростить проектирование, повысить качество кода и снизить вероятность ошибок.

Основные идеи DRY:

1️⃣ Устранение дублирования
Если код или логика повторяются — выноси их в отдельный модуль, функцию или класс. Так любые изменения потребуют правки только в одном месте.

2️⃣ Упрощение поддержки
Меньше дублирования → проще тестировать и обновлять код. Никаких "а не забыл ли я поправить это в другом файле?"

3️⃣ Улучшение читаемости
Чистый и структурированный код легче понимать и поддерживать.

💡 Как применять DRY?
Используй функции, классы, библиотеки и паттерны проектирования, чтобы избежать повторений.

🎯 Как мы применяем DRY с учениками?

✔️ Логгирующий клиент — один класс для всех логов, а не копипаста в каждом тесте 📋.
✔️ Хелперы и врапперы  — позволяет зашить логику проверок, разметки и другие полезные действия в одном месте, тем самым появляется как бы "авторазметка" и "автопроверки", так как использование методов из классов уже содержит все необходимое.
✔️ Декораторы  — позволяет добавлять новый функционал к уже существующим методам, всего одной строчкой.
✔️ Фасады — позволяют определить одну входную точку в нужный клиент, вместо написания большого количества очень похожих фикстур.
✔️ Используем наследование и другие возможности языка, для уменьшения дублирования кода.

Использование этих подходов позволяет здорово улучшить поддерживаемость, стабильность и чистоту кода нашего фреймворка.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

В посте выше в комментариях верное отметили, что говоря про DRY, нужно не забывать про KISS.

Принцип KISS (Keep It Simple, Stupid) — один из ключевых в разработке.
Его суть проста: чем проще ваш код, тем легче его поддерживать, масштабировать и понимать (вам и другим разработчикам).

Почему KISS важен?

1️⃣  Меньше багов — сложный код = больше ошибок.
2️⃣ Лучше читаемость — коллеги (и будущий вы) скажут спасибо.
3️⃣ Быстрее разработка — не нужно изобретать велосипед.

Я точно знаю, что есть проекты написанные мной еще 4 года назад, которые работают и поддерживаются по сей день. Все потому, что были написаны очень просто и понятно, как молоток.

Как применять KISS?

✔️ Дробите задачи — одна функция = одна ответственность.
✔️ Избегайте "умного" кода — если решение требует сложных объяснений, возможно, есть вариант проще.
✔️ Рефакторите — если код стал запутанным, упрощайте без жалости.
✔️ Используйте проверенные паттерны — но не усложняйте там, где можно без них.

"Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать."

Ваш код должен решать задачу, а не демонстрировать интеллект. Старайтесь писать проще!

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Принцип YAGNI (You Ain’t Gonna Need It) — «Тебе это не понадобится»

Часто на картинках с DRY и KISS мелькает еще один важный принцип — YAGNI. Он гласит: не добавляй функциональность, которая может понадобиться в будущем, но не нужна прямо сейчас.

Основные идеи YAGNI:
1️⃣ Не реализуй то, что не требуется сейчас — если нет конкретного ТЗ, не пиши код «на всякий случай».
2️⃣ Избегай ненужной сложности — лишний код усложняет поддержку и тестирование.
3️⃣ Оптимизируй только при необходимости — преждевременная оптимизация может навредить.
4️⃣ Экономи время и ресурсы — меньше лишнего кода = чище и понятнее архитектура.

Примеры нарушения YAGNI:

- Абстрактная архитектура «на будущее», которая никогда не пригодится.

- Параметры в функции, которые пока не используются.

- Сложная система логирования для одноразового скрипта.

Хороший принцип… но я его нарушаю в автотестах😅

Вот как и почему:

🔹 Генерация клиентов
Если писать клиенты вручную, логично описать только нужный контроллер для нужного API сервиса. Но я давно использую сгенерированные клиенты — и если генерировать, то все сразу.

🔹 Версии API (V1, V2, OLD и т. д.)
Контроллеры в разных версиях API могут называться одинаково, и появляются фикстуры вроде old_controller_api, v2_controller_api и т. п. Проще сразу сделать фасад, который объединит API (контроллеры) одного сервиса, где через точку можно доставать нужный, вместо того чтобы путаться в версиях контроллеров.

🔹 Обёртки над методами
Контракты меняются, и если не подготовиться, придётся переписывать все тесты, а не один метод-абстракцию. Поэтому я довольно часто добавляю еще один класс, в виде наследника от API клиента, в котором упрощаю интерфейс тестируемого метода.

Да, это усложняет проект, но зато даёт архитектуру, которую легко поддерживать годами.
А если все это генерировать это вовсе сводит трудозатраты к минимуму, задавая чёткие рамки проекта.

Вывод: YAGNI — хорошее правило, но иногда его можно нарушать осознанно. Главное — понимать, зачем.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Отзыв на курс Advanced, запоздалый немного, но вот только созрел)

Когда отзыв приходит не сразу — это тоже хорошо.
Значит, человек не просто посмотрел курс, а пожил с ним.

Вот кусочек одного такого отзыва на курс Advanced:

«Сейчас пробую свои собственные проекты писать по этой же структуре и все реально легко работает, прописал основные моменты и дальше остается только описывать апишку и шаги тестов, все работает красиво с первых дней)».

✔️ Вот за это я и люблю поздние фидбэки.

Курс отлежался в голове, прошёл через пару шишек, и вдруг всё встало на свои места.

Читаемость, структура, простота — это не случайно.

🔥Вот ради этого и делался Advanced.
Весь курс построен так, чтобы после него можно было не “переизобретать”, а спокойно писать API-тесты на понятной архитектуре, без боли и гадания, «как бы тут лучше».

И самое приятное — когда люди возвращаются за следующей ступенью.
Значит, не просто зашло, а стало частью рабочего процесса.

Спасибо за отзыв — и жду на 🏆 про-уровне, когда придёт время.

Полный отзыв можно прочитать тут.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

“Ты не хуже, просто у тебя не было нужного тренера.”

Недавно мой ученик написал:

«К нам пришёл человек с 4 годами опыта в автотестах — и он знает ровно столько же, сколько я.»

Он добавил:

«я хотел сказал, что с таким учителем как ты я развил потенциал и опыт меньше чем за год.»

Это не про меня. Это про силу правильного подхода.
Про то, как практика, структура, и обучение дают больше, чем 4 года «просто работы».


Что даёт результат быстрее опыта в вакууме?
• Фокус не на инструментах, а на понимании архитектуры
• Практика, приближённая к реальным задачам на проекте
• Преподаватель, который объясняет


Если ты:
• Хочешь не просто «писать тесты», а строить фреймворки
• Чувствуешь, что время идёт, а прогресса нет
• Или уже в тестировании, но хочешь расти как инженер —
присоединяйся.

Ты не отстаёшь. У тебя просто ещё не было правильной траектории.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Fuzzing тестирование API

В этом канале мы с вами рассматриваем преимущественно темы автоматизации тестирования API.

У меня все никак не доходили руки рассказать про инструмент, который вы возможно даже использовали и который занимается fuzzing тестированием.

🔍 Что такое фаззинг-тестирование?

Фаззинг (fuzzing) — это метод автоматического тестирования, при котором программа проверяется на уязвимости и ошибки с помощью передачи случайных или полу-случайных данных на вход. Цель — найти краш, утечку памяти, неожиданное поведение или уязвимости безопасности.

🧩 Виды фаззинга:

- Мутационный фаззинг — изменяет существующие входные данные (например, искажая корректный JSON).

- Генеративный фаззинг — создает данные с нуля на основе спецификации (например, OpenAPI/Swagger).


А теперь собственно про сам инструмент.

⚡️ Schemathesis — фаззер для API

Schemathesis — это инструмент для тестирования API, основанный на OpenAPI/Swagger-схеме сервиса. Он автоматически генерирует тестовые сценарии и "обстреливает" ваш API некорректными или неожиданными данными, чтобы выявить:

- Ошибки сервера (500 Internal Server Error)
- Уязвимости (SQL-инъекции, XSS)
- Проблемы валидации
- Неожиданное поведение

🚀 Как работает?

1. Берет схему OpenAPI/Swagger.

2. Генерирует корректные и некорректные запросы на основе property based testing.

3. Отправляет их в API и анализирует ответы.


🔧 Пример использования:

pip install schemathesis  
schemathesis run https://example.com/openapi.json  

Или с кастомными параметрами:

schemathesis run --checks all --max-response-time 5000 http://api.example.com/schema.json

💡 Зачем это нужно?

- Находить баги до продакшена.
- Улучшать отказоустойчивость API.
- Автоматизировать тестирование безопасности.

На практике имеет смысл использовать скорее если вы вылизываете свое API и у вас есть ресурсы, чтобы упороться, кривые схемы будут порождать огромное количество ошибок которые с высокой долей вероятности никто не будет править.

Инструмент безумно простой в использовании и очень эффективный, в целом можно внедрить отдельной не блокирующей гитлаб джобой с заделом на будущее. Кстати недавно обнаружил, что он еще умеет в GraphQL

Думаю добавлю урок с этим инструментом в курс Advanced, лишним не будет)

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Всем привет!
Поздравляю с прошедшими майскими праздниками, но.

Майские - закончились. Время включаться.

Шашлыки -были. Отдых - был.
Теперь - время расти как инженер.

Сегодня стартует новый поток курса по API-автотестированию.
И это последний день, когда можно впрыгнуть в этот поток.

После этого набор закрываю.

Если ты хочешь:
- разбираться в архитектуре
- писать уверенный продакшн-код
- не просто “ковыряться в Postman”, а строить фреймворки

Переходи по ссылке и выбирай нужный модуль.

Успей сегодня.

Работаем.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

“Если оно ходит как утка… 🦆” — питон не требует паспорта.

А вы знали, что Python поддерживает несколько видов типизации? 🤔

Например:
- 🦆 Утиная
- 🦢 Гусиная
- 📜 Статическая утиная типизация
- 🔍 Статическая типизация

В этом посте поговорим про ту типизацию, которая изначально была в Python — Утиную.

Одно время я все никак не мог понять, что это такое. Если вы уже в теме — отлично! Если нет — сейчас расскажу.

Python — язык про поведение, а не про формальности. 

Здесь не так важно, от какого класса ты наследуешься.
Важно, что ты умеешь делать!

Пример:
Представь, тебе нужна "последовательность": список, массив, колода карт — не суть.

Python не будет проверять, наследуешься ли ты от `list` или `collections.abc.Sequence`.

Он просто попробует вызвать:

- __len__()
- __getitem__()

Если получилось — значит, ты "последовательность". ✅

class FrenchDeck:  
    def __init__(self):  
        self._cards = []  

    def __len__(self):  
        return len(self._cards)  

    def __getitem__(self, pos):  
        return self._cards[pos]  

🔎 Обратите внимание:  этот класс ни от кого не наследуется!

Но его можно:
- перебирать в цикле,
- брать срезы,
- передавать в `sorted()`, `random.choice()` и т.д.

Потому что он ведёт себя как список!

То есть тебе просто нужно реализовать нужные методы — и этого достаточно.

🦆 Что такое утиная типизация?

“Если что-то ходит как утка, крякает как утка — значит, это утка.”

Такой подход даёт гибкость:
- Можно писать адаптивный код без лишней иерархии.
- Главное — понимать, какие "протоколы поведения" ждёт от тебя Python.

Хочешь разбираться в таких концепциях глубже?
Учись читать поведение, а не только сигнатуры!

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Гусиная типизация — когда утки 🦆 недостаточно
(а интерфейс всё-таки нужен)

В Python есть утиная типизация — “если выглядит как утка и крякает как утка — это утка”.
Это удобно. Но не всегда безопасно.

Название «гусиная типизация» возникло как противопоставление «утиной»: если утиная типизация в Python ориентируется на поведение объекта (если у него есть нужные методы — значит, подходит), то гусиная делает акцент на происхождение — как в биологии, где гусей и уток раньше классифицировали по внешнему сходству, но позже стали объединять по общим предкам (кладистика). Аналогично в программировании: два класса могут иметь одинаковые методы (например, draw()), но с разным смыслом — и потому они не обязательно взаимозаменяемы. Гусиная типизация требует явного указания интерфейса через абстрактные базовые классы (ABC) — чтобы быть уверенным, что объекты действительно «родом» от нужного интерфейса, а не просто «выглядят похоже».

Иногда нужно чётко сказать:
“Я реализую этот интерфейс” — и получить защиту на уровне кода.

Вот тут появляется гусиная типизация 🦢.

Что это такое?

Гусиная типизация — это подход к проверке типов во время выполнения, основанный на использовании абстрактных базовых классов (ABC).

Да, в Python нет ключевого слова interface, но есть модуль abc, который позволяет создать интерфейс через абстрактный класс.

Пример:

from abc import ABC, abstractmethod

class MessageSender(ABC):
    @abstractmethod
    def send(self, message: str) -> None:
        pass

class TelegramSender(MessageSender):
    def send(self, message: str) -> None:
        print(f"Отправлено в ТГ: {message}")

class EmailSender:
    def send(self, message: str) -> None:
        print(f"Письмо: {message}")

Теперь можно сделать проверку:

isinstance(TelegramSender(), MessageSender)  # True
isinstance(EmailSender(), MessageSender)     # False

Хотя EmailSender реализует метод send, он не унаследован от MessageSender.
Python этого не “засчитает” — и это отличие от утиной типизации.

❓Для чего это нужно?
- Когда важно явно указать, что ты реализуешь интерфейс
- Когда нужна статическая проверка типов (например, через mypy)
- Когда hasattr() уже не спасает и хочется чёткости и надёжности

✔ Коротко:
- Утиная типизация — поведение важнее наследования
- Гусиная типизация — поведение + явная декларация через ABC
- Поддерживается isinstance(), issubclass() и статическими анализаторами

В Python можно писать и гибко, и строго — выбор за тобой.

Понимание обеих моделей делает твой код читаемым, надёжным и масштабируемым.

В глоссарии Python есть статья посвященная абстрактным базовым классам.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Статическая утиная типизация — когда нужно понять, что это утка, ещё до запуска.

Мы уже с вами узнали:
• Утиная типизация — “если выглядит как утка и крякает как утка — это утка”
• Гусиная типизация — “эта утка официально записана в реестре как утка” (через ABC)

Теперь познакомимся с третьим подходом — статической утиной типизацией через Protocol.

Что это такое❓
Protocol из модуля typing позволяет описать интерфейс по ожидаемому поведению — без наследования.
Если у объекта есть нужные методы — он считается совместимым.

from typing import Protocol

class Writer(Protocol):
    def write(self, data: str) -> None: ...

class FileWriter:
    def write(self, data: str) -> None:
        print(f"Пишу: {data}")

def save(w: Writer, msg: str):
    w.write(msg)

save(FileWriter(), "Привет!")

Обрати внимание: FileWriter не наследует Writer, но типовые анализаторы (mypy, pyright) поймут — всё ок.
Потому что поведение совпадает.


Зачем это нужно❓
• Статическая проверка интерфейсов до запуска
• Без isinstance() и жёсткой иерархии
• Отлично подходит для тестов, моков
• Совместим с mypy, Pyright, Pylance и другими инструментами
• С полной свободой: хочешь — наследуй, хочешь — просто реализуй нужные методы


Утиная типизация была про “смотрим, что умеет объект”.
Статическая утиная — про “давайте это ещё и проверим заранее”.

✔️ Коротко:
• Protocol — это интерфейс без наследования
• Работает по принципу “если поведение совпадает — значит, подходит”
• Используется для статической проверки типов
• Совместим с mypy, Pyright и другими анализаторами

Можем ли мы проверить, что утка это утка используя протокол в рантайме?
Да например так:

from typing import Protocol, runtime_checkable

@runtime_checkable
class Writer(Protocol):
    def write(self, data: str) -> None: ...

class FileWriter:
    def write(self, data: str) -> None:
        print("Пишу:", data)

fw = FileWriter()

print(isinstance(fw, Writer))  # True

🧠 Статическая утиная типизация помогает писать гибкий, но при этом безопасный код.
Это некий баланс между свободой и контролем.


Более подробно про протоколы можно почитать тут.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Впереди выходные, почему бы не уделить это время тюнингу своего гитхаб аккаунта)

💻 Как оформить GitHub-профиль, чтобы он работал на вас.

Если вы пишете код, GitHub — это не просто хранилище кода. Это ваша публичная визитка. Грамотно оформленный профиль помогает:

🔹 Привлечь внимание рекрутеров и заказчиков
🔹 Выделиться среди других кандидатов
🔹 Показывает, что вы заботитесь о деталях и уважаете своих коллег по цеху
🔹 Да и в целом даже самому приятно смотреть на красивый профиль.

📌 Что можно сделать:
– Создать README для профиля с краткой информацией о себе
– Выделить ключевые проекты и красиво их оформить
– Добавить бейджи, статистику и немного стиля
– Подчеркнуть свою активность, навыки и интересы

Сделать это довольно просто, достаточно просто создать репозиторий с названием своего GH профиля и положить туда README.

👀 Нашёл пару отличных гайдов, которые помогут навести порядок и сделать профиль действительно заметным:

📄 Как информативно оформить профиль на GitHub?
📄 Оформляем README-файл профиля на GitHub

Но сильно не увлекайтесь, слишком много свистелок перделок тоже не есть хорошо))

Если давно хотели прокачать свой профиль, но откладывали — самое время ✌️
А если уже что-то сделали — кидайте ссылки, интересно посмотреть!

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Статическая типизация в Python — когда уткам уже не доверяешь 🧊

Python — язык с динамической природой.
Но что, если хочется надёжности уже до запуска?

Добро пожаловать в мир статической типизации.
Без уток, без гусей — просто строгая проверка типов.

🧐 Что это вообще?

Статическая типизация — это когда ты явно указываешь типы переменных, аргументов и возвращаемых значений, а специальные инструменты (например, mypy) проверяют это до выполнения кода.

def greet(name: str) -> str:
    return f"Привет, {name}"

greet("Питон")       # Всё хорошо
greet(123)           # mypy тут же даст ошибку

Python по-прежнему выполнит код, даже если ты передашь int, но анализатор заранее скажет: «что-то не так».

На этом примере особо не почувствуешь плюсов. Но если ты работаешь с большим количеством DTO, например pydantic модели, запросов и ответов или у тебя большой проект, когда ты не знаешь ожидаемых типов становится очень тяжело программировать. Среда разработки подсказывает хуже.
В общем сейчас я рекомендую всем по возможности проставлять аннотации.

📌 Как это работает?
• Используется синтаксис аннотаций (x: int, -> str)
• Проверка идёт снаружи, через инструменты (mypy, pyright, IDE)
• Ошибки ловятся ещё до запуска (в идеале — на этапе CI)

⚖️ Зачем это нужно?
• Уменьшить баги, так как python при запуске не выбрасывает ошибки при расхождении типов.
• Упростить навигацию по коду (IDE покажет сигнатуры, автокомплит и т.п.)
• Улучшить читаемость: ты сразу видишь, что принимает и возвращает функция
• Повысить доверие к чужому коду: «ничего не сломаю, если передам вот это»

На ступени Advanced мы пишем код практически без аннотаций, но на Professional мы уже используем статическую типизацию и инструменты для анализа нашего кода.

🔥 Советы:
• Начинай с простого: добавляй типы в публичные функции
• Используй mypy — он легко интегрируется в проекты
• Не бойся писать Optional, Union, TypedDict, Literal — они реально спасают

✔️ Коротко:
• Python остаётся динамическим, но может быть типизированным
• Статическая типизация помогает ловить ошибки до запуска
• Ты не обязан, но ты можешь — и это делает код сильнее

🎯 Итог:
Утиная типизация даёт свободу.
Гусиная — структуру.
Статическая — уверенность.

А вместе они дают тебе гибкий, читаемый и защищённый код.

Про модуль typing и type hints можно почитать в официальной доке.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы