Еще про исключения:
repr(e) -- это, конечно хорошо, но ведь есть ещё лучше, а именно:
from traceback import print_exc
...
my_dict = {}
try:
b = my_dict["bad"]
except Exception as e:
print_exc()
что выведет:
Traceback (most recent call last):
File "<pyshell#1>", line 2, in <module>
KeyError: 'bad'
и при этом программа продолжит свою работу. А если ошибку надо выводить не в stdout, то можно сделать так:
from traceback import print_exc
from io import StringIO
...
try:
b = my_dict["bad"]
except Exception:
buffer = StringIO()
print_exc(file=buffer)
out_var = buffer.getvalue()
992 · Дублирование объектов в множестве
Предположим, у нас есть сервер и его клиенты. Мы хотим отслеживать состояние клиентов на сервере и управлять ими. Для этой цели мы будем добавлять клиентов в коллекцию, чтобы избежать случайного дублирования одного и того же клиента на сервере.
Давайте создадим класс Client и добавим его в коллекцию (я также добавил метод repr для красивого вывода):
class Client:
def init(self, user_name):
self.user_name = user_name
def repr(self):
return self.user_name
fish1 = Client(user_name="catfish")
clients = set()
clients.add(fish1)
print(clients) # {catfish}
Замечательно, всё работает как задумано! Теперь попробуем добавить второго клиента и убедимся, что дублирования не происходит:
fish2 = Client(user_name="catfish")
clients.add(fish2)
print(clients) # {catfish}
Как это возможно? Мы добавили два абсолютно идентичных экземпляра в коллекцию, ожидая, что останется только один, но оба остались.
При добавлении объекта в коллекцию интерпретатор следует следующему правилу:
если a == b, то hash(a) == hash(b) должно быть обязательно выполнено.
То есть, интерпретатор сравнивает объекты не только напрямую, но также сравнивает их хеши.
Для сравнения объектов, коллекции и словари используют магический метод eq. Для пользовательских объектов этот метод определен по умолчанию. По умолчанию, два разных объекта не считаются равными, даже если они абсолютно идентичны:
print(fish1 == fish2) # False
По умолчанию все объекты в Python также имеют хеш-значение (хеш), которое рассчитывается из их идентификатора (id). Когда мы пытаемся добавить объект в коллекцию, мы используем магический метод hash этого объекта, который также определен по умолчанию. Часто люди думают, что хеш объекта совпадает с его адресом в памяти, но это не всегда так:
🦑 В Python 2.6 и более ранних версиях hash(x) = id()
🦑 В Python 2.6 и более поздних версиях: (https://bugs.python.org/issue5169) hash(x) == id(x)/16
То есть, нельзя полагаться на то, что hash(x
2 · 1.5K · S Всем привет! У меня есть канал про становление программистом, подписывайтесь, кому интересно) @python_in_my_heart
Фотография
нажмите — покажем
нажмите — покажем
🖥Microsoft интегрировала Python в Excel
Все популярные библиотеки Python (pandas, statsmodels и matplotlib) стали доступны для создания графиков и диаграмм. Для реализации всего этого появилась новая функция "PY"
5 · 1.1K · Фотография
нажмите — покажем
нажмите — покажем
Топ популярных горячих клавиш, для PyCharm:
Ctrl + D — Дублировать строку, когда пишешь схожие строки, теперь нет надобности набирать их сначала или выделять и копировать.
Ctrl + R — Решил переименовать класс? Изменит имя во всем проекте.
Ctrl + Shift + N — Поиск класса или метода по всему проекту.
Ctrl + Alt + M — Написали код, теперь захотели его обернуть в функцию, вот сочетание.
Ctrl + Alt + S — Перейти в настройки.
Ctrl + Y — Удалить строку.
Ctrl + B — Переместиться к данному классу.
Ctrl + F12 — Показывает структуру данных файла.
Alt + F7 — Посмотреть где используется данный класс, метод или функция.
Ctrl + Shift + U — Быстро изменить регистр слов.
Ctrl + Alt + L — Быстрое форматирование кода по стандарту PEP 8.
Ctrl + Shift + ↑ ↓ — Для быстрого перемещения строк или блоков.
Ctrl + W — Выделить текущий блок.
36 · 1.6K · Вышла первая бета Django 5.0, а значит значимого изменения состава релиза уже не будет и можно смотреть, что завезли:
1. Много поддержки асинхронности - в contrib.auth, возможность получить и обработать asyncio.CancelledError внутри вьюхи, если клиент разорвал соединение до того, как мы закончили обрабатывать запрос, поддержка асинхронки в куче декораторов, асинхронная отправка сигналов, новые асинхронные методы у моделек
2. На первом месте довольно спорная фича - возможность показывать количество фильтруемых объектов в боковом фильтре в админке. Там под капотом COUNT и естественно на более-менее приличных объемах данных тормозить будет нечеловечески. Благо можно глобально отключить
3. Упрощенная шаблонизация для форм из коробки, для тех кто работает с html-формами код станет читабельнее (хотя думается мне, что те кто работает с большими формами уже давно что-то подобное у себя реализовали)
4. Возможность задавать дефолты на уровне базы данных
5. `GENERATED`-поля в моделях, значение которых рассчитывается на уровне БД
6. В Choice-полях теперь можно использовать словарь, вместо кортежей
В общим никаких революций https://docs.djangoproject.com/en/5.0/releases/5.0/
30 · 6.7K · Ссылка
нажмите — покажем
нажмите — покажем
Новости nogil. Steering Council принял PEP 703 - опциональный gil из коробки. На discuss.python.org большой пост про это, я приведу только заинтересовавшие меня моменты:
Пока нет уверенности, что выпиливание gil не поломает совместимость со сторонними либами, не сделает интерпретатор медленнее на 10–15% и не усложнит его поддержку. Выбрали вполне ожидаемый подход - реализуем и посмотрим, как пойдет, потому что на прототипах и теоретических выкладках далеко не уедешь.
Как и предполагали раньше, все будет происходить в несколько этапов:
1. Возможность отключить gil на этапе сборки — это точно не продакшен решение, а инструмент для авторов библиотек и экспериментаторов
2. Финализация изменений API и ABI, после чего nogil-сборка будет уже считаться не экспериментальной но все еще не включаться по дефолту
3. Отключенный gil по умолчанию с возможностью включить при сборке
В общем планируют переходить очень постепенно и не загонять людей в светлое будущее палкой вплоть до того, что готовы отозвать PEP 703 если переход окажется слишком калечащим.
https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075
13 · 4.3K · Фотография
нажмите — покажем
нажмите — покажем
Коллеги, Поделитесь своим опытом! 🐍
Мы готовим материал по вопросам для собеседования разработчиков Python и нуждаемся в вашей помощи. Расскажите, какие интересные, необычные и сложные вопросы вам задавали на собеседованиях? 🤔
Ваш опыт поможет нам создать настоящий арсенал вопросов. Пожалуйста, поделитесь своими историями и вопросами в комментариях ниже. 💬
🐍 🐍Python🪆GPT: Конечно, вот некоторые интересные вопросы, которые могут быть полезными при собеседовании кандидата на позицию Python-разработчика: 1. Основы Python: - Какие различия между Python 2 и Python 3 вы знаете? - Чем отличается кортеж от списка (tuple vs list)? - Что такое генераторы (generators) и в чем их преимущество? 2. Объектно-ориентированное программирование (ООП): - Что такое класс и объект в Python? - В чем разница между наследованием и композицией? - Что такое магические методы (magic methods) в Python и для чего они используются? 3. Работа с базами данных: - Какие библиотеки для работы с базами данных вы использовали в Python? - Как выполнить SQL-запрос в Python? - Чем отличается SQL база данных от NoSQL базы данных? 4. Web-разработка: - Какие фреймворки для веб-разработки вы использовали в Python? - Что такое RESTful API и как его создать с использованием Python? - Как обрабатывать исключения во Flask (или другом веб-фреймворке)? 5. Тестирование и отладка: - Какие тестовые фреймворки вы использовали в Python? - Какие инструменты отладки Python вы знаете? 6. Асинхронное программирование: - Что такое асинхронное программирование и почему оно важно в современных веб-приложениях? - Как работают асинхронные функции в Python (async/await)? - Какие библиотеки для асинхронного программирования вы использовали? 7. Безопасность: - Какие методы обеспечения безопасности вы использовали в ваших проектах на Python? - Как избежать уязвимостей типа инъекций (SQL injection, XSS) в Python-приложениях? - Что такое хэширование паролей и как его реализовать в Python? 8. Оптимизация и производительность: - Какие методы оптимизации кода вы знаете в Python? - Что такое GIL (Global Interpreter Lock) и как он влияет на многопоточное выполнение в Python? - Какие инструменты профилирования вы использовали для оптимизации производительности Python-приложений? 9. Работа с файлами и сетью: - Как читать и з- 🦇 Е S Ссылка
нажмите — покажемПривет. Кому не сложно, загляните сюда. Может кому-то будет интересно https://t.me/bugbuntyworld_ru
Всем привет!
Мы запустили новый удалённый проект и находимся в поиске партнёров!
Уделяя всего пару часов свободного времени в день вы можете зарабатывать от 25 000 рублей в день!
Все что необходимо это: стабильный интернет и телефон
Мы обучаем и поддерживаем 24/7
Нам нужны активные и ответственные люди.
Если тебе интересно — напиши мне «+» и узнай что для этого необходимо
Фотография
нажмите — покажем
нажмите — покажем
Интеграции с внешними системами: как не превратить backend в зоопарк адаптеров
Рано или поздно backend обрастает интеграциями: платежи, CRM, учётные системы, доставка. Если не договориться с собой о правилах — код быстро начинает жить по законам чужих API.
Несколько вещей, которые реально помогают не потерять контроль над архитектурой.
1. Anti-corruption layer
Не смешивайте доменные модели с ответами партнёров. Лучше выделить отдельный слой.
class PaymentGateway:
async def create_payment(self, dto: PaymentDTO) -> Payment:
...
Контракт у партнёра изменился — правки остаются в одном месте.
2. DTO как точка входа
DTO — удобное место для валидации и нормализации данных.
@dataclass
class PartnerOrderDTO:
external_id: str
total: Decimal
На этом этапе проще отфильтровать неконсистентные данные, чем ловить баги дальше в домене.
3. Idempotency
Повторы запросов — нормальная история для любой сети.
Idempotency-key или уникальный индекс часто спасают от дублей и лишних списаний.
4. Retry без фанатизма
Бесконечные retry под нагрузкой легко добивают зависимый сервис — а заодно и ваш.
Обычно хватает ограниченного числа попыток с backoff.
Чем меньше домен знает о чужих форматах, тем спокойнее переживаются изменения во внешних системах.
175 · Фотография
нажмите — покажем
нажмите — покажем
Ваш backend слишком сложный. Скорее всего — без причины.
У большинства команд сложность растёт незаметно.
Сначала “давайте сразу сделаем правильно”, потом появляются абстракции, фабрики, менеджеры менеджеров — и через полгода никто не понимает, как это работает.
Плохая новость: сложность почти всегда дороже железа.
Несколько тревожных сигналов:
— Новый разработчик боится трогать код
— Любое изменение требует правок в 5 слоях
— Архитектуру нужно объяснять на созвоне
— Без схемы в Miro ничего не ясно
Частая причина — преждевременное масштабирование. Система ещё не испытывает нагрузку, а её уже проектируют как Netflix.
Что обычно работает лучше:
1. Простые сервисы
Если класс нельзя объяснить за 30 секунд — он почти наверняка перегружен.
2. Меньше “универсальных” решений
Код, который “подойдёт на будущее”, часто не нужен вообще.
3. Оптимизация по фактам
Сначала метрики → потом усложнение. Не наоборот.
4. Локальная понятность
Открыл файл — понял, что происходит. Это underrated свойство хорошего backend-а.
Интересный парадокс:
сильные инженеры чаще упрощают систему, а не усложняют её.
Иногда лучший архитектурный рефакторинг — это удаление половины кода.
145 · Фотография
нажмите — покажем
нажмите — покажем
Как на самом деле работает отбор резюме в 2026 году
Современный найм — это не «человек читает ваше резюме».
Это нейронайм: автофильтры, парсеры и быстрые решения рекрутеров.
Большинство кандидатов отсеиваются до того, как их резюме кто-то осознанно посмотрит.
Базовые фильтры, о которых не говорят вслух
- Опыт менее 3 лет в большинстве случаев автоматически ведёт к отказу.
- Возраст ниже 25 лет часто не проходит первичную фильтрацию, даже если это нигде не написано.
- Отсутствие ключевых слов в блоке навыков = отказ.
Автопарсеры сопоставляют резюме с вакансией по совпадению терминов, а не по смыслу.
Учебные практики и стажировки не считаются коммерческим опытом.
Неайтишный бэкграунд не усиливает резюме айтишника — он его размывает.
Что не стоит указывать в резюме
❌ Желаемый доход
❌ Личные соцсети
❌ Фотографию
🖥GitHub не всегда важен и редко смотрится на этапе фильтрации.
Образование в большинстве случаев вообще не проверяется.
Зато важно:
👉 указывать стек технологий отдельно для каждой компании, а не общим списком.
Резюме — это продажа, а не автобиография
Успешный программист умеет продавать себя.
Продажи в найме бывают:
- тупыми — «я хороший, возьмите меня»
- умными — «я закрываю вашу боль»
На HeadHunter обязательно используйте инструменты, которые повышают ваш статус в выдаче.
Это напрямую влияет на количество просмотров.
Не тратьте время на «подтверждение навыков».
Лучше используйте репозиторий на GitHub как опору, а не как главный аргумент.
Умная продажа — это:
- правильное позиционирование,
- попадание в запрос работодателя,
- демонстрация пользы, а не личности.
Как должно выглядеть сильное резюме
Резюме — это рекламный буклет, а не отражение вашей души.
Через него нужно донести:
- умение общаться,
- способность решать задачи,
- ответственность за результат.
Каждое место работы описывается по одному шаблону:
Контекст — где и в каких условиях вы работали
Достижения — что изменилось благодаря вам
Стек — конкретные технологии
Достижения оформляются
4 · 179 · Фотография
нажмите — покажем
нажмите — покажем
«Какой навык самый важный для разработчика?»
Ответ неожиданно простой — умение учиться быстрее других.
В книге «The Only Skill That Matters» Джонатан Леви показывает: в мире, где технологии меняются каждые 2–3 года, выигрывает не самый умный и не самый опытный. Выигрывает тот, кто быстрее осваивает новое.
Разберём идеи, которые особенно полезны нам — разработчикам.
🧠 1. Учёба — это навык, а не талант
«У меня плохая память» — это не приговор.
Память тренируется так же, как мышцы.
Если вы можете выучить синтаксис нового фреймворка — вы уже тренируете её.
📚 2. Пассивное чтение = иллюзия прогресса
Просто читать документацию — мало.
Гораздо эффективнее:
— писать мини-конспекты
— формулировать вопросы к тексту
— пересказывать материал своими словами
— объяснять коллеге или близким
Если не можешь объяснить ребенку — значит, не понял.
⏳ 3. Интервальные повторения > «зубрёжка»
Повторять нужно не сразу, а через интервалы:
1 день → 3 дня → неделя → месяц
Так знания переходят в долгосрочную память.
И да, это работает лучше, чем «перед дедлайном всё перечитать».
🎯 4. Сначала структура, потом детали
Не нужно запоминать всё подряд.
Сначала разберитесь:
— какая архитектурная идея стоит за технологией
— какие 20% дают 80% понимания
— какие основные сущности и связи
После этого детали ложатся сами.
🔥 5. Фокус — множитель скорости
Мультизадачность = медленное обучение.
Если изучаете новый инструмент:
— закройте Telegram
— уберите уведомления
— выделите 40–60 минут глубокой концентрации
Один час глубокого фокуса = 3 часа «в фоновом режиме».
🎓 6. Учись через преподавание
Самый быстрый способ разобраться в сложной теме — написать о ней пост.
Или объяснить её стажёру.
Или записать короткое видео.
Объяснение структурирует знания лучше любого конспекта.
———————
В 2026 году побеждает не тот, кто знает больше. Побеждает тот, кто быстрее освоит:
— новый паттерн
— новую библиотеку
— новый стек
— новую архитектуру
или 1с🤣
Самый ценный навык разработчика — скорость адап
5 · 209 · Фотография
нажмите — покажем
нажмите — покажем
«Пузырь лопнул», «айти всё», «рынок умер» — каждый раз читаем это с новым интересом.
Но давайте без лишних эмоций.
Факты такие:
— массового “схлопывания” рынка нет.
— но перегретого найма 2021–2022 тоже больше нет.
— зарплаты растут медленнее инфляции.
— конкуренция среди джунов выше.
— компании стали осторожнее.
Бизнес — это борьба за ресурсы.
Разработчик — это ресурс.
Если вы понимаете это — половина тревожных постов перестаёт действовать.
Когда аутсорс-компания пишет «рынок сложный, зарплаты падают, берите что дают» — это не аналитика. Это позиция покупателя на переговорах.
Им выгодно, чтобы вы верили, что:
— работы мало
— альтернатив нет
— нужно соглашаться быстрее
Те, у кого входящий поток предложений, просто идут дальше.
Те, кто сомневается — начинают демпинговать сами себя.
Это обычная стратегия закупки.
В IT разная реальность:
• в стартапе разработчик — это расход до момента масштабирования
• в крупной компании — это генератор огромной добавленной стоимости
Отсюда и разница в ощущениях «рынок плохой» / «работы полно».
Не каждый бизнес хочет «побеждать рынок».
Некоторые модели работают на минимальных расходах и живут за счёт экономии.
Им выгодны дешёвые специалисты.
Им выгодна паника.
Поэтому вопрос всегда один:
Кто это пишет и чьи интересы стоят за сообщением?
За последние годы рынок стал более зрелым и спокойным. Но сезонность, циклы и спрос никуда не делись.
Айти не умерло! Оно просто перестало быть лёгким. А лёгкое — заканчивается всегда.
Работать нужно лучше. Позиционироваться — умнее. И не читать аналитику от тех, кто покупает ваш труд.
Спокойствие — тоже конкурентное преимущество.
245 ·