Это больше похоже на плохую архитектуру, язык здесь вторичен.
Мапы объектов можно и в типизированных языках передавать.
Если нет требования по производительности, просто делайте всё неизменяемым и создавайте обхект нового типа на каждной стадии. Если нет, то паттерн строитель.
Датаклассы не очень помогут, Any | None поменятеся на int | None и поля будут определены. Если вы не можете посчитать состояния объекта по пальцам одной руки, это уже сложно для восприятия. Два optional поля дают 4 варианта состояния. None(еще на заполнен) и None(Заплненное значение) это два разных стостояния, но из вообще не отличить.
Можно видеть проблему “опережающей ссылки”. Наш класс в одном из методов хочет вернуть экземпляр самого себя, но не сможет этого сделать, поскольку объект класса еще не определен, пока Python не закончит вычисление его тела. В этом случае мы вынуждены записать возвращаемое значение в виде строки.
Я так понял это код нарузочных тестов от компании автора статьи.
База как раз не тупит, а со старой версией тестов, могла переварить все на что способна машина которая теститрует. Машину упирался в предел потоков и приходилось использовать несколько машин.
В примере не вижу, чтобы использовались асинхронные библиотеки в связке с синхронными.
Пул потоков в данном случае не асинхронный.
Виртуальные потоки придуманы как раз для того, чтобы писать привычный синхронный код, а вся "асинхронность" уйдет в недра JVM. И авторы project loom везде предупреждают, что с synchronized блоками и native это работать не будет (в лучшем случае не будет никакого полезного эффекта), о чем и написано в конце статьи.
Задумка хороша, просто пока надо знать много деталей реализации, чтобы это приносило пользу.
Проблема в том, что код с synchronized может находится глубоко внутри используемых библиотек
Асинхронные библиотеки плохо работают в связке с синхронными. Например асинхронный веб сервер будет так-себе, если использовать синхронный клиент внутри.
В Java, во имя обратной совместимости, порой реализовывают интерфейсы через одно место. Например объект типа List созданный черезunmodifiableList имеет метод add, который бросает рантайм исключение.
Ну и комбо асинхронный объект в интерфейсе Thread. При малом количестве задач, это часто будет просто неэффективный код, который гоняет event loop, но по факту гоняте всё синхронно на ThreadPool. Ну а если задач много, то всё подвиснет, как в статье.
Асинхронность это очень крутой инструмент, но кроме производительности он открывает бездны возможностей сделать всё еще медленней.
По копирайтеским статьям технология звучит как крутая. У вас был опыт с нею в проде? Легко ли собрать низковисящие фрукты просто добавив анатаций к части методов или всплывают всякие нюансы и овчинка выделки не стоит?
Профильные эксперты в комментариях к публикации пояснили
А как же Бри́тва Хэ́нлона?
По молодости надо было общаться с утсройством по телнету. Я допустил две ошики: не закрывал соединение после использования и создавал коннекшен на каждый запрос.
Минут через 5 коллега сидящий рядом стал громко высказывать своё удивление состоянием внутренней сети, которую я положил.
Если такие мелочи важны, то стоит еще посмотреть на что-то типа grpc.
Да, так рекомендовано делать внутри периметра для оптимизации трафика между серверами. Цифры для этого случая в статье и есть.
Выгялдит как сравнение ряди сравнения.
В реальности я скорее всего возьму простой фреймворк на Питоне. Узким местом скоее будет сеть или возможности сервиса.
Было бы интересно посмотреть результаты на средних и крупных запросах.
Еще HTTPS бы не мешало потестить. Хотя это уже потребует менять методику.
Мне кажется в реальной жизни разница будет сильно меньше, возможно даже неразличимо меньше.
Они переписали его на rust.
А вот trafaret на питоне. https://github.com/Deepwalker/trafaret/
Да, только проверил дату публикации.
Убирать не стал, так как второй обзац сфокусирован на другой проблеме и про что он решает "опережающей ссылки" нужно самому додуматься.
Посмотрел доку, а этот PEP до сих пор не включили в Питон.
Я его перепутал с https://peps.python.org/pep-0604/ которого мне в 3.9 не хватет.
Кроме коллкеций который переехали, там есть и другие вещи.
Хотя большую часть из них я боюсь использовать в продакшен коде, сложновато. Питон не главный язык в команде и не все в него глубоко погружены.
В Питоне сильная типизация. А еще она динамическая.
Это в простых случаях. А в сложных в Питоне просто забиваешь и работает, а в статических языках придётся решать. А там это делать куда сложнее.
Это больше похоже на плохую архитектуру, язык здесь вторичен.
Мапы объектов можно и в типизированных языках передавать.
Если нет требования по производительности, просто делайте всё неизменяемым и создавайте обхект нового типа на каждной стадии. Если нет, то паттерн строитель.
Датаклассы не очень помогут, Any | None поменятеся на int | None и поля будут определены. Если вы не можете посчитать состояния объекта по пальцам одной руки, это уже сложно для восприятия. Два optional поля дают 4 варианта состояния. None(еще на заполнен) и None(Заплненное значение) это два разных стостояния, но из вообще не отличить.
Приветствую тебя гость из прошлого.
В 3.9 можно вот так:
https://peps.python.org/pep-0563/
Не хватает в выводах про удобство работы с Фигма и навели ли порядок в файлах. Стали ли процессы добавления нового контента удобнее и быстрее?
Звучит немного громко. Это всего лишь еще одна реализация асинхронности. Идее уже не один десяток лет и асинхронные код можно было писать и раньше.
Придумали тут только новую обертку для этого. Со своими плюсами и минусами.
Я так понял это код нарузочных тестов от компании автора статьи.
База как раз не тупит, а со старой версией тестов, могла переварить все на что способна машина которая теститрует. Машину упирался в предел потоков и приходилось использовать несколько машин.
Пул потоков в данном случае не асинхронный.
Задумка хороша, просто пока надо знать много деталей реализации, чтобы это приносило пользу.
Асинхронные библиотеки плохо работают в связке с синхронными. Например асинхронный веб сервер будет так-себе, если использовать синхронный клиент внутри.
В Java, во имя обратной совместимости, порой реализовывают интерфейсы через одно место. Например объект типа List созданный через
unmodifiableList
имеет метод add, который бросает рантайм исключение.Ну и комбо асинхронный объект в интерфейсе Thread. При малом количестве задач, это часто будет просто неэффективный код, который гоняет event loop, но по факту гоняте всё синхронно на ThreadPool. Ну а если задач много, то всё подвиснет, как в статье.
Асинхронность это очень крутой инструмент, но кроме производительности он открывает бездны возможностей сделать всё еще медленней.
Тайминги по любому будут абстрактными. На одних задачах и наборах данных будет работать, на других нет.
У меня в основном io-bound задачи или мало данных, мне не на чем своём попробовать.
По копирайтеским статьям технология звучит как крутая. У вас был опыт с нею в проде? Легко ли собрать низковисящие фрукты просто добавив анатаций к части методов или всплывают всякие нюансы и овчинка выделки не стоит?
И даже векторизация к ним есть https://numpy.org/doc/stable/reference/generated/numpy.vectorize.html
А как же Бри́тва Хэ́нлона?
По молодости надо было общаться с утсройством по телнету. Я допустил две ошики: не закрывал соединение после использования и создавал коннекшен на каждый запрос.
Минут через 5 коллега сидящий рядом стал громко высказывать своё удивление состоянием внутренней сети, которую я положил.