а в луп запихал авейтов понаставил и радуйся

То есть треды проще чем корутины?

Ну ну

Корутина повисла и всё, кердык

А тред проге не мешает

я вообще-то наоборот имел ввиду(

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

При установке с их серверов то же самое пишет

ну там много приколов, например те же самые ексепшены, о которых ты узнаешь только когда луп всё наружу выплюнет

пацаны, пизда рулю, даже линукс поставить не могу, настолько все плохо. Винда опять распоясалась

поскольку я всегда знал, что Дуров замутил ТГ неубиваемым, оно есть таким и сейчас. Например, я не могу получить доступ к сайтам, да даже гугл не пингуется! А вот тыгэ работает, как ни в чем ни бывало. Кстати, я щас по проводу сижу, так время от времени эта шайтан-машина переключается между вафлей и проводом

с телефона все работает прекрасно, плюс линия полностью свободна, выдает тридцатку mbps

Ну а чем плох синхронный, когда есть треды? ;-)

Попробуйте создать штук 50000 тредов

Попробуйте создать штук 50000 тредов

А часто у тебя 50000 параллельных корутин?

Попробуйте создать штук 50000 тредов

Создать без проблем можно, хоть миллион)

Создать без проблем можно, хоть миллион)

+

А часто у тебя 50000 параллельных корутин?

Ну, попробуйте 100 тредов, просто на 50000 разница прямо в глаза бросается.

100 корутин у меня часто бывает

При установке с их серверов то же самое пишет

Ну тогда из сорцов, увы

Зачем нужны корутины тоже ещё надо суметь объяснить

Да я больше не про объяснение того как это работает внутри, а про то, что человек говорил, что не понимает зачем вообще использовать yield. Вот асинхронщина хороший пример в том плане, что тебе в любом случае приходится использовать корутины (можно конечно и на callback'ах все писать, но кто так будет делать?)

Ну, попробуйте 100 тредов, просто на 50000 разница прямо в глаза бросается.

На 100 тредах вообще никаких проблем

На 100 тредах вообще никаких проблем

Ну с тредами все же больший оверхед будет, но да, будет работать

Ну с тредами все же больший оверхед будет, но да, будет работать

Ну вот это ещё надо измерить по хорошему.

А сколько памяти занимает один поток в пайтон?

Предполагаю чуть больше чем в любом другом языке

Это реальный поток ОС

ну и от платформы наверное еще будет зависеть

На 100 тредах вообще никаких проблем

Ну да, переключения gil вообще фигня.

Ну да, переключения gil вообще фигня.

переключение контекста ты хотел сказать?

если ты сравниваешь асинхронщину и трединг - предполагается что у тебя io bound, при чем тут gil

gil не переключается, он захватывается

Ну да, переключения gil вообще фигня.

Эм, окей. Треды + процессы. Но вообще я про вытесняющую многозадачность vs кооперативную. Эффект не всегда очевиден и не всегда однозначен

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

Можно подумать у тебя в корутинах больше одного куска питоновского кода работает

Но переключения дешевле и не рандомны

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

боль от большого кол-ва thread'ов/процессов не особенно связана c GIL, проблема из-за того что context switch довольно дорогая операция. Это не связано вообще с ЯП

Но переключения дешевле и не рандомны

Именно. Дешевле и ты должен их аккуратно контролировать.

А ещё асинхронность на корутинах в случае cpu-bound задач требует ручного переключения

боль от большого кол-ва thread'ов/процессов не особенно связана c GIL, проблема из-за того что context switch довольно дорогая операция. Это не связано вообще с ЯП

В третьем питоне gil еще рандомно отпускается во время выполнение кода, что приводит к расходам сверх переключения контекста

А что лучше при Парсинга данных с сайтов, треды или асинхронщина?

Асинхронщина

в твоем случае лучше асинхронка

Именно. Дешевле и ты должен их аккуратно контролировать.

Можно подумать, что многопоточность на тредах проста

Можно подумать, что многопоточность на тредах проста

Для многих задач проще. особенно если юзать не всякие мьютексы, а готовые очереди и прочее

треды лучше использовать если есть тесное общение между потоками и есть использование i/o

А ещё асинхронность на корутинах в случае cpu-bound задач требует ручного переключения

Мне кажется, для cpu задач обычно используют c-extensions, которые обходят gil, или что-то типа celery

Или когда вообще независимые части

Короче, речь была о том, что плюс asyncio не так очевиден

Мне кажется, для cpu задач обычно используют c-extensions, которые обходят gil, или что-то типа celery

Можно подумать celery - это не разные процессы обработчики.

И да, почему вы сразу о тредах. Есть процессы

с языка снял

Для многих задач проще. особенно если юзать не всякие мьютексы, а готовые очереди и прочее

А в питоне есть очереди на тредах? Опять же, в очень большом пласте задач (привет, веб-приложения), где синхронизация не уперлась, асинхронщина очень даже ничего

Можно подумать celery - это не разные процессы обработчики.

Ну так не треды же.

И кстати, кто-то из присутствующих гонял тесты, на каком числе параллельных задач с i/o появится заметное ускорение от использования корутин вместо тредов/процессов?

Короче, речь была о том, что плюс asyncio не так очевиден

ну уж нет. Событийная обработка io гораздо эффективнее тредов, просто при малом кол-ве задач, это может быть не сильно заметно

И кстати, кто-то из присутствующих гонял тесты, на каком числе параллельных задач с i/o появится заметное ускорение от использования корутин вместо тредов/процессов?

эта проблема называется c10k

ну уж нет. Событийная обработка io гораздо эффективнее тредов, просто при малом кол-ве задач, это может быть не сильно заметно

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

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

Понятно, что в определнных сценариях разница может быть менее заметна. Но в целом thread'ы (независимо от ЯП) приводят к context switch'ам

кто за тайпинг шарит?

как можно указать аннотацию что лист возвращает только 1 элемент?

или достаточно бредовая затея?

как можно указать аннотацию что лист возвращает только 1 элемент?

что значит list возвращает только один элемент?

можешь пример кода привести?

длина = 1

а зачем такой list нужен?

ну если уж надо то используй tuple

list сам по себе может быть любой длины. Поэтому такого тайпхинта существовать не может

Tuple[int]

ну это я знаю...

а зачем тебе именно mutable коллекция из одного элемента?

а зачем тебе именно mutable коллекция из одного элемента?

она не совсем мне нужна, она может вернутся из метода, нужно глянуть...

метод выплёвывает List[Dict]

но, в каких-то краевых случаях я знаю что будет всего 1 дикт внутри

и где тебе тогда нужен такой тайпхинт?

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

наверное, перемудрил)

Можно переделать метод чтобы он возвращал Union[List[Dict], Dict], но в коде потом все равно придется делать проверку на то какой тип вернулся. Так что смысла в этом нет, проще провереть длину list'а

если возвращаемы тип зависит от типа входных параметров, то можно еще @overload использовать

Есть кстати безумная идея

Типы с ограничениями по допустимым значениям

Например, что какая-то целая переменная бывает только от 1 до 100. Или список с длиной не больше 5

Литералы есть, в екстеншинах

Добро пожаловать в контрактное программирование

Добро пожаловать в контрактное программирование

Это понятно. Речь о питоне

Литералы есть, в екстеншинах

Хм

Гляну

уже началось первое апреля и теперь это чатик контрактного программирования?

да, литералы в одной из последних версий mypy завезли

Например, что какая-то целая переменная бывает только от 1 до 100. Или список с длиной не больше 5

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

уже смотрю, да