Наконец то норм фронтэнд на питоне? А мне только недавно зашел Next.js...

https://x.com/jeremyphoward/status/1818036923304456492

https://fastht.ml

Надо попробовать на досуге.

Вот бывает такая фигня, работаешь в своем бранче, никого не трогаешь, но тут надо тесты писать. Написал, запускаешь nox, показывает что coverage 99% где то в совсем другой части проекта, никак не связанной с твоим кодом. Начинаешь вопрошать мол как оно попало в master? Стягиваешь master, запускаешь nox и показывает зеленый билд... Меняешь бранч, показывает что проблема все таки есть. Снова в master обратно, и уже и там показывает что все плохо. Но ведь это все уже в мастере, вот как так? А github actions который у нас там подвязан в CI/CD тоже показывает зеленый билд 🥲

Я эти тесты на одном месте крутил. Особенно если их писал не я. Это конечно не часто случается, но когда проект содержит десятки тыщ строк кода, может случиться и такое.

В каком то из давних интервью меня попросили предсказать вывод следующего Python-кода:

class A:
    pass

class B:
    value = 1

class C:
    value = 3

class D(A, B, C):
    def __str__(self):
        return str(self.value)

print(D())

Эту проблему на тот момент я не мог решить, но я ее запомнил и вернулся к ней только недавно. Ключ к решению этой задачи лежит в понимании т.н. Method Resolution Order (MRO) в Python. MRO определяет порядок, в котором происходит поиск базовых классов при обращении к методу или атрибуту.

💡 В данном случае D наследуется от A, B и C. Но когда мы печатаем D(), атрибут value берётся из класса B! Почему?

Вот объяснение:
1️⃣ Python ищет value в классе D.
2️⃣ Затем он смотрит в A, но A не имеет value.
3️⃣ Далее он проверяет B — и находит value = 1.

Поскольку B стоит перед C в MRO, используется value из B, поэтому вывод будет 1! ⚙️

Вы можете увидеть MRO с помощью D.mro():

[<class '__main__.D'>, <class '__main__.A'>, <class '__main__.B'>, <class '__main__.C'>, <class 'object'>]

@hw_code

каким-то мистическим образом проблема разрешилась... Вот есть что-то такое в этой зелёной галочке эээ успокаивающее?

Я в последнее время часто сижу в Твиттере. Там собралась большая техническая тусовка: люди постоянно создают новые проекты и стартапы, зарабатывают деньги и делятся опытом. После выхода того самого интервью с Лексом Фридманом и Питером Левелсом (ну про Фридмана-то вы наверняка слышали?), там активно обсуждают, нужно ли действительно "вылизывать" свои приложения, делать тесты и писать код "как надо", а не как хочется. Питер высказывался о том, что все эти TDD, Vercel, крутые базы данных и прочее — не так уж и важны. Он буквально на коленке создал вирусные AI-проекты, которые приносят огромные деньги. Инди-хакеры тут же подхватили эту идею и начали постить, мол, да, надо пушить в продакшен сразу, тесты не нужны, вообще всё не нужно — хочу и пушу говнокод прямо в мастер. "Что вы мне сделаете?" Поэтому мне интересно, что вы думаете по этому поводу:

Мда, если даже здесь всё не так однозначно... Ладно, вот вам ещё один спорный тезис. Кто-то в обсуждениях заметил, что некоторые программерские инструменты будто бы специально сделаны сложными в использовании. Например, те же СУБД (почему-то не люблю это слово). Postgres — это, конечно, мощно, но если у вас тоже возникал вопрос: почему бы не использовать MySQL или даже sqlite, то вы не одиноки. На примере того же Левелса можно отметить, что его сервера выдерживают большой наплыв пользователей, несмотря на использование самых простых инструментов, таких как sqlite. Я, честно говоря, вообще не уверен знает ли он, что есть асинхронная обработка реквестов и т.д. (интересно, как оно на пыхе там?).

Можно долго спорить, но у каждого инструмента есть свои причины для использования. Если ваш проект используют всего трое человек (вы и ещё два фаундера), возможно, не стоит стремиться "сделать всё идеально с самого начала". Но это больше про предпринимательство. Пока нет чёткого видения product market fit, нет смысла усложнять процесс разработки. Если нужно будет, перепишите потом. Одно дело — работать в корпорации, где стабильно платят и цена ошибки не так велика (я знаю примеры, когда тулзы разрабатывали буквально годами, чтобы в итоге сказать "всё, мы решили забросить этот проект"), и совсем другое — когда денег нет и нет чёткого понимания рынка (нужно разработать быстро).

не, ну фабричка то пусть там все равно пыхтит туда сюда... если надо, на Rust перепишем 👍

докер и микросервисы это залупа конченая, а фирмы которые это используют просто страдают “shiny new framework syndrome”.

Change my mind.