да и в pypy тоже

я сравнивал варианты с map - всё равно компрехеншены быстрее

да в том коде воообще не понятно зачем так...

что-то типа v[0] - sum(v[1:]) например, ну так, из головы

да не, код там очевидный имхо человек с помощью мапа и лямбды меняет знак у всех элементов со второго, впидарасивает первый элемент на первое место и сует это всё в сум() в итоге выходит a-b-c-d-e...

редьюс с вычитанием просто просится на замену

v[0] - sum(v[1:])

это то что просится

можно и так

и вывать руки обоим, за оригинал и за редьюс

ну арифметика 2-й класс

при этом, насколко я понимаю, редьюс умрет на списке из одного элемента

остальные два варианта на пустом списке

а, не

>>> import operator >>> reduce(operator.sub, [0]) 0

все три варианта помрут на пустом 8)))

1 поставь

[1]

>>> reduce(operator.sub, [1]) 1

не, редьюс вернет как есть

хм...

а если вписать 0 третьим аргументом, то будет работать и на пустом списке

>>> l = [] >>> l[0] - sum(l[1:]) Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range >>> reduce(operator.sub, l, 0) 0

ага.

редьюс безопаснее)

кстати

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

v[0] - sum(v[1:])

reduce быстрее на больших списках в pypy

я сегодня увидел next(iter(filter(...)), 0)

ну, второй питон, естессн.

ну, next да

https://docs.python.org/3/library/functools.html?highlight=reduce#functools.singledispatch ой

list.pop(0) или next(l). оба кинут исключение на пустом, поэтому надо комбинировать с тернарным

next(l, 0) не кинет.

а, у некста дефолт таки есть. у лист.попа увы нету

угу

а у дикт.поп есть 8\

Я чего и спорил то с овнером кода

тоже думал есть

100000 loops, best of 3: 66.4 µs per loop для reduce(operator.sub, v) 100000 loops, best of 3: 114 µs per loop для v[0] - sum(v[1?)

У листа есть pop

У листа есть pop

да да:)

но у его pop нет default

более того, он модифицирует список

ну что поделать

массив тогда уж.

а?

array? :)

Потому что это не список, да)

это спорное утверждение

ну ну

трудности перевода и оригинальной терминологии одноврменно

Скажи лучше, где посмотреть клёвое использование штук из functools?)

типа того синглдиспатч что ты скинул

выглядит интересно, но ничего придумать не получилось(

Ну, можно поискать по github

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

да обычно это хорошо ложится на специфические задачки

Но, оно по первому аргументу, так что только через костыли

ой

только по первому

я думал там по полной сигнатуре было

Открываем, читаем, по ссылке написано

да я пеп читал когда он вышел

Ну вот, функция по доке вот так работает

ZCA покошернее будет таки

ERROR: S client not available

https://docs.python.org/3/library/functools.html?highlight=reduce#functools.singledispatch ой

а как оно по скорости бьёт?

так там небось тот же isinstance

https://github.com/igrishaev/f#generics

если кому интересно то сейчас начнётся трансляция https://www.youtube.com/watch?v=HqKe_tu4sFU

кафушки

смотрю

при чем тут gil и io? gil отпускается, когда передается управление другому треду. на блокирующем io этого не происходит.

Так прям и не отпускается gil? https://docs.python.org/2/glossary.html#term-global-interpreter-lock

Also, the GIL is always released when doing I/O.

Ладно, всем спасибо. Но, я так понимаю, что опыта решения подобной проблему ни у кого нет?

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

мда

Чтобы это значило?

Тшшшш

В тырнети кто-то не прав.

вот так люди и изобретают микросервисы

вот так люди и изобретают микросервисы

ты говоришь как будто это что-то плохое

нет, но как бы от необходимости сочетания синка и асинка это не избавляет

нет, но как бы от необходимости сочетания синка и асинка это не избавляет

а ты пойдешь завтра в пивнуху?

нет, но как бы от необходимости сочетания синка и асинка это не избавляет

Это предложение решить конкретную проблему. Есть конструктивная критика предложения?

а ты пойдешь завтра в пивнуху?

до той пивнухи мне всего-то тыщ пять километров

до той пивнухи мне всего-то тыщ пять километров

это откуда ты откладываешь?

Это предложение решить конкретную проблему. Есть конструктивная критика предложения?

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

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

1. Даже если они будет спать как ты выразился это не мешает другому потоку обработать реквест если говорить про многопоточность. Отвечать ты будешь так быстро как позволит тебе твоя база поэтому число потпотоков/процессов (в зависимости от того что выберешь исходя из того на чем это запускается) будет пропорционально тому количеству запросов которые может твоя база потянуть. 2. Никто не отменял возможность запустить это виски приложение под gevent и не блокироваться вовсе. 3. насколько потеря на сериализацию значительна без профилирования это демагогия, а с учётом что у изначального решение использовался синхронный драйвер из торнадо так вообще смешно об этом говорить

1. Даже если они будет спать как ты выразился это не мешает другому потоку обработать реквест если говорить про многопоточность. Отвечать ты будешь так быстро как позволит тебе твоя база поэтому число потпотоков/процессов (в зависимости от того что выберешь исходя из того на чем это запускается) будет пропорционально тому количеству запросов которые может твоя база потянуть. 2. Никто не отменял возможность запустить это виски приложение под gevent и не блокироваться вовсе. 3. насколько потеря на сериализацию значительна без профилирования это демагогия, а с учётом что у изначального решение использовался синхронный драйвер из торнадо так вообще смешно об этом говорить

Gevent тут не спасет.

если у тебя 50 процессов торнады 80% времени спали и ждали базу, то сколько процессов твоей замечательной прослойки понадобится? и сколько процессов можно будет оставить от торнады? Улучшится ли утилизация процессора? Ты каждый запрос к базе (да еще и через sqlalchemy) превратишь в отдельный http эндпоинт? сколько у тебя времени это займет? сколько багов будет в сериализации?

Потому что выполняя блокирующиеся операции ты будешь блокировать весь gevent

если у тебя 50 процессов торнады 80% времени спали и ждали базу, то сколько процессов твоей замечательной прослойки понадобится? и сколько процессов можно будет оставить от торнады? Улучшится ли утилизация процессора? Ты каждый запрос к базе (да еще и через sqlalchemy) превратишь в отдельный http эндпоинт? сколько у тебя времени это займет? сколько багов будет в сериализации?

Чтобы было 80 процессов торнадо надо иметь 80 ядер в системе :)

тсс

да даже если 20

Потому что выполняя блокирующиеся операции ты будешь блокировать весь gevent

Ты представляешь как работает gevent? Почему пропаченый socket будет блокироваться? Зачем его тогда пачить? :)

Ты представляешь как работает gevent? Почему пропаченый socket будет блокироваться? Зачем его тогда пачить? :)

Причем тут сокет?

Ну когда ты запрос в базу делаешь ты с каким примитивном работаешь ?

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