Инкапсуляция в Python: property, name mangling и никаких кофемашин

Нормальная инкапсуляиция - выделение интерфейсов, когда вы просто заявляете что есть, а об остальном потребитель ни сном ни духом. Все эти "private" в языках наследников c++ - от бедности, когда технтчески понадобилось светить все внутренности потребителю класса и не надо проводить с ними параллели и пытаться повторить.

PEP — это не стиль, это язык, которым ты думаешь о коде

Рекомендую начать с PEP 1: https://peps.python.org/pep-0001/

А потом обратить внимание на PEP 0: https://peps.python.org/pep-0000/

И мой любимый PEP 404: https://peps.python.org/pep-0404/

Распил монолита в 2026: а может, не надо? Как AI переворачивает закон Конвея

микросервисы решали проблему человеческой памяти архитектурными средствами. AI решает проблему человеческой памяти напрямую, без архитектурных костылей.

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

Архитектурные границы и правила организации кода - это как раз способ не держать в конетксте всё и уметь быстро найти. Нарушьте это и ваша нейросеть будет страдать так же как человек.

Как обычному разработчику попасть в сообщество открытого ПО и стоит ли это делать

А пожалуйста, расскажите про "низкокачественные места", очень хочу послушать

Urich: DDD и CQRS для микросервисов на Starlette без ручной раскладки роутов

Хотелось бы чтобы доменный слой можно было организовывать исходя из потребностей конкретного домена, а натягивать на примитивы фреймворка. Например, почему бы не существовать операциям, затрагивающим несколько агрегатов. И куда делись все дополнительные адаптеры, доменные сервисы и стратегии которые мы тоже хотим инжектировать? А как насчет приложений которые не имеют постоянного стейта в бд? Много вопросов, не надо превращать DDD в CRUD

Urich: DDD и CQRS для микросервисов на Starlette без ручной раскладки роутов

А можно, пожалуйста, не тащить в домен фреймворки?

Git-хуки, которые не дают коммитить плохой код

В пет проекте у меня покрытие 93%. Какой же это кайф рефакторить. Я на днях взял и переписал значительный кусок и просто следил что все тесты прошли. Если бы у меня их не было, я не знаю как бы с этой задачей справился - очень много вещей стреляло, о которых я уже даже не помнил

Git-хуки, которые не дают коммитить плохой код

Плюсы и js не закладывают в отступы семантику. Код не меняет из-за отступов, можно форматировать как угодн. В питоне сиутация не такая - изменение форматирования может сломать код, поэтому форматирование закладывается на этапе написания - как вижу так он работать и будет. И вот если вдруг ты решил закоммитить сырой сломанный код (мало ли что случилось, очень надо), некоторые форматтеры могут решить что отформатировать его всё равно надо и что-то куда-то передвинуть

Git-хуки, которые не дают коммитить плохой код

Пусть улучшает отдельным коммитом. А то так улучшит, что не откатить потом

Git-хуки, которые не дают коммитить плохой код

Окончанием мысли могу быть тесты. Сломанные :) потому что как их чинить - это другая мысль

Git-хуки, которые не дают коммитить плохой код

Я в пет проекте сейчас 2 недели пилю новую сложную фичу. До стабильной версии ещё много, постоянно что-то не так. Мне не коммитить?

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

Git-хуки, которые не дают коммитить плохой код

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

Мемоизация в Python: как заставить код помнить

Почему функции работают долго?
Обычно это происходит по трем причинам:

3) Рекурсия — когда функция вызывает саму себя.

Нет, рекурсия не является причиной проблемы

И рекурсивный код и нерекурсивный могут работать одинаково долго просто потому что код так написан (с ошибками или намеренно для упрощения реализации).

Универсальный компилятор для FPGA, который понимает 42 языка программирования

А как же "Пишите код на любимом языке"?

Как Markdown захватил мир

В markdown вообще разрешено html использовать

Claude Code в 2026: гайд для тех, кто еще пишет код руками

Открыл свой компьютер, не увидел там вашего кода Block Blast. Вы уверены, что именно так происходит демонстрация ваших результатов?

Claude Code в 2026: гайд для тех, кто еще пишет код руками

с 100% покрытием unit и e2e тестами.

а можно посмотреть что за тесты там?

как насчет метрики покрытия тестами требований?

Код, за который стыдно: 5 ошибок, которые нельзя допускать в Python

я не знаю julia, можете показать как будут выгдятеть аналоги этого кода?

def new_generator(default: int):
   def number_generator(arg: int=default):
      return arg
   return number_generator

def baz(generator=new_generator(1)):
   pass

Код, за который стыдно: 5 ошибок, которые нельзя допускать в Python

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

Код, за который стыдно: 5 ошибок, которые нельзя допускать в Python

А к тому, что разное поведение def foo(bar=1) и def foo(bar); bar=1 это плохо.

А разное повдение y=x; x=x+1 и x=x+1; y=x? Это разные вещи и делают они разное. Более того, оно иногда и используется намеренно (хотя мы осуждаем).