Comments 14

Обычно магия дает возможностиписать меньше кода. Но тут надо писать больше кода. И одно дело, писать больше кода при создании либы или ядра. А тут надо писать больше кода при использовании.


Такой код не решает скриптовые проблемы питона. Он только подчеркивает и усиляет эти проблемы.

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

Такой код призван решать динамические проблемы. Почему он «подчеркивает и усиляет эти проблемы»?
Могу, конечно, согласиться, что в Python это выглядит не так хорошо, как в некоторых других ЯП.

За что мы любим Никиту Соболева — только он умеет писать на Питоне так, что хочется плакать и переходить на Джаву.

@kinded
def fetch_resource_size(
    client_get: Callable[[str], Kind2[_IOKind, httpx.Response, Exception]],
    url: str,
) -> Kind2[_IOKind, int, Exception]:
    return client_get(url).map(
        lambda response: len(response.content),
    )

Beautiful is better than ugly, и тогда это питон. Я вижу не питон. Я понимаю, что есть Особые причины (и продакшен подгорает), но в режиме питона — спасибо, нет.

чувствую, чего-то не хватает…
недосказанность присутвствует…
где же
public static override bool
?

А что будет если нужно просуммировать длину ответа трех ПОСЛЕДОВАТЕЛЬНЫХ запросов? Где, скажем, url второго получаем из ответа первого, а url третьего — из второго?


Для того, чтобы записать, скажем такую странную штуку:


result = 0
for _ in range(3):
    response = await client_get(url)
    result += len(response.content)
    url = response.content

придется использовать вложенность (которую чаще именуют callback hell'ом). Ну или вызовы asyncio.run в коде везде, где раньше случалось встретить await, превращая код в по-настоящему синхронный. И в любом случае — плохо читаемый.


Можно тысячу раз спросить "а на..., простите, зачем?!" глядя на цикл с await выше, но никак не "а что, собственно, этот код делает?". Чего, боюсь, не скажешь о коде, написанном с помощью описанного в статье подхода.

По-идее, тут надо просто сделать монадический reduce, и результат будет вполне себе читаем…


…но я не нашёл его в рекламируемой библиотеке.

Глядя на это превращение "псевдокода" в простыни нечитаемого текста, могу лишь предложить другое название статье:


Какая асинхронность должна была бы быть в Python

-> Какая асинхронность должна была бы убить Python

Во-первых, перепишем императивный псевдокод в функциональный.
Сразу возник вопрос о целесообразности дальнейшего чтения.
Асинхронность чаще всего применяется на задачах со значительной долей ввода/вывода (читай, с побочными эффектами), как сюда вписывается функциональная парадигма?

Глядя на пример функции, которая работает "и так и так", у меня встает один вопрос: а как я ее буду тестировать.? Не получится ли, что функция "и так и так" внутри вызывает другую функцию, которая один из "таков" не поддерживает? А если таких две, и одна работает только синхронно, а вторая только асинхронно, и вызываются они в зависимости от фазы луны? По-моему, тут требуется универсальная поддержка со стороны языка (все функции одного цвета — красного и синего сразу фиолетового), как в го, например, а не костыль, который надо форсить разработчику в каждой строчке проекта.

Не получится ли, что функция "и так и так" внутри вызывает другую функцию, которая один из "таков" не поддерживает?

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

что только не сделают люди, чтобы не переходить на elixir, go или haskell.

Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 February 2008

Location

Россия

Employees

11–30 employees

Registered

24 February 2010

Habr blog