Pull to refresh
15
0
Send message

Если такие мелочи важны, то стоит еще посмотреть на что-то типа grpc.

Да, так рекомендовано делать внутри периметра для оптимизации трафика между серверами. Цифры для этого случая в статье и есть.

Выгялдит как сравнение ряди сравнения.

В реальности я скорее всего возьму простой фреймворк на Питоне. Узким местом скоее будет сеть или возможности сервиса.

Было бы интересно посмотреть результаты на средних и крупных запросах.

Еще HTTPS бы не мешало потестить. Хотя это уже потребует менять методику.

Мне кажется в реальной жизни разница будет сильно меньше, возможно даже неразличимо меньше.

Pydantic обновил мажорную версию (вместе с ней и рекорды скорости).

Они переписали его на rust.

А вот trafaret на питоне. https://github.com/Deepwalker/trafaret/

Да, только проверил дату публикации.

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

Посмотрел доку, а этот PEP до сих пор не включили в Питон.

Я его перепутал с https://peps.python.org/pep-0604/ которого мне в 3.9 не хватет.

Кроме  коллкеций который переехали, там есть и другие вещи.

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

Проблема в слабой типизации.


В Питоне сильная типизация. А еще она динамическая.

Аннотирование функций в питоне подравнивает ситуацию по объёму писанины


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

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

Мапы объектов можно и в типизированных языках передавать.

Если нет требования по производительности, просто делайте всё неизменяемым и создавайте обхект нового типа на каждной стадии. Если нет, то паттерн строитель.

Датаклассы не очень помогут, Any | None поменятеся на int | None и поля будут определены. Если вы не можете посчитать состояния объекта по пальцам одной руки, это уже сложно для восприятия. Два optional поля дают 4 варианта состояния. None(еще на заполнен) и None(Заплненное значение) это два разных стостояния, но из вообще не отличить.

Можно видеть проблему “опережающей ссылки”.  Наш класс в одном из
методов хочет вернуть экземпляр самого себя, но не сможет этого сделать,
поскольку объект класса еще не определен, пока Python не закончит
вычисление его тела. В этом случае мы вынуждены записать возвращаемое
значение в виде строки.


Приветствую тебя гость из прошлого.

В 3.9 можно вот так:

from __future__ import annotations

https://peps.python.org/pep-0563/

Не хватает в выводах про удобство работы с Фигма и навели ли порядок в файлах. Стали ли процессы добавления нового контента удобнее и быстрее?

Виртуальные потоки придумали как раз для реальной жизни.


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

Придумали тут только новую обертку для этого. Со своими плюсами и минусами.

Я так понял это код нарузочных тестов от компании автора статьи.

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

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


Пул потоков в данном случае не асинхронный.

Виртуальные потоки придуманы как раз для того, чтобы писать привычный синхронный код, а вся "асинхронность" уйдет в недра JVM. И авторы project loom везде предупреждают, что с synchronized блоками и native это работать не будет (в лучшем случае не будет никакого полезного эффекта), о чем и написано в конце статьи.

Задумка хороша, просто пока надо знать много деталей реализации, чтобы это приносило пользу.

Проблема в том, что код с synchronized может находится глубоко внутри используемых библиотек


Асинхронные библиотеки плохо работают в связке с синхронными. Например асинхронный веб сервер будет так-себе, если использовать синхронный клиент внутри.

В Java, во имя обратной совместимости, порой реализовывают интерфейсы через одно место. Например объект типа List созданный черезunmodifiableList имеет метод add, который бросает рантайм исключение.

Ну и комбо асинхронный объект в интерфейсе Thread. При малом количестве задач, это часто будет просто неэффективный код, который гоняет event loop, но по факту гоняте всё синхронно на ThreadPool. Ну а если задач много, то всё подвиснет, как в статье.

Асинхронность это очень крутой инструмент, но кроме производительности он открывает бездны возможностей сделать всё еще медленней.

Тайминги по любому будут абстрактными. На одних задачах и наборах данных будет работать, на других нет.

У меня в основном io-bound задачи или мало данных, мне не на чем своём попробовать.

По копирайтеским статьям технология звучит как крутая. У вас был опыт с нею в проде? Легко ли собрать низковисящие фрукты просто добавив анатаций к части методов или всплывают всякие нюансы и овчинка выделки не стоит?

Профильные эксперты в комментариях к публикации пояснили

А как же Бри́тва Хэ́нлона?

По молодости надо было общаться с утсройством по телнету. Я допустил две ошики: не закрывал соединение после использования и создавал коннекшен на каждый запрос.

Минут через 5 коллега сидящий рядом стал громко высказывать своё удивление состоянием внутренней сети, которую я положил.

Information

Rating
Does not participate
Registered
Activity