Pull to refresh

Comments 14

UFO just landed and posted this here

зато выглядит круто, 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.

Sign up to leave a comment.