threading в пайтоне нормального нет, только симуляция его

есть, просто не для питонокода

про симуляцию

сишные либы могут тредить

есть, просто не для питонокода

Ну мы ж говорим про чистый пайтон?

Сишные да

Ну мы ж говорим про чистый пайтон?

ну, не бывает чистого питона, там обертки над си же

там полноценные обычные потоки, просто синхронизированные при помощи GIL

и есть места, где gil отпускается

там полноценные обычные потоки, просто синхронизированные при помощи GIL

что никак тебе, как разработчику, не помогает, к сожалению

gil отпускается на IO примитивах

там свои мютексы

gil отпускается на IO примитивах

ну потому что там вызовы в ядро, логично

что никак тебе, как разработчику, не помогает, к сожалению

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

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

причем тут асинхронность, когда мы про потоки говорим?

нонеча 95% тасок требующих многопоточности - io-bound

если ты пишешь именно код на питоне - то тебе в абсолютном большинстве случаев потоки не нужны

использовать чистый питон для намбер-кранчинга изначально стремная идея

в любом случае

если ты пишешь именно код на питоне - то тебе в абсолютном большинстве случаев потоки не нужны

если мне нужны (а они мне часто нужны), то я их использую

проблема в том, разве что, для io задач в контексте asyncio нет до сих пор полноценной библиотеки драйверов для всех задач

если мне нужны (а они мне часто нужны), то я их использую

в питонокоде от этого профита нет, одни убытки

в питонокоде от этого профита нет, одни убытки

ложь

ложь

нет

GIL

для параллелизации ио - ваще отлично

Вот про потоки вопрос

Есть скрипт в цикле который пользователям шлет письма

GIL

если у меня 10 потоков из которых 9 в состоянии sleep, то GIL мне только помогает

Хочу веб морду добавить, чтоб пользователей править

еще раз объясняю. У тебя в контексте исполнения питонокода каждый отдельный байткод интерпретатора должен выполняться атомарно. GIL позволяет это сделать, но при этом у тебя тупо не сможет питонокод несколько потоков одновременно выполнять

Это лучше отдельным потоком делать или отдельным скриптом?

если у меня 10 потоков из которых 9 в состоянии sleep, то GIL мне только помогает

да, но если это io задача - то asyncio справится, скорее всего, лучше

Это лучше отдельным потоком делать или отдельным скриптом?

это лучше написать морду отдельно, а скрипт отдельно

да, но если это io задача - то asyncio справится, скорее всего, лучше

скорее всего так же, но asyncio оверкилл ненужный

и синхронизировать их на базе

это лучше написать морду отдельно, а скрипт отдельно

Просто 2 пай скрипта будет?

скорее всего так же, но asyncio оверкилл ненужный

нет, asyncio - это самый современный вариант работы с подобными вещами

Просто 2 пай скрипта будет?

смотря как напишешь

нет, asyncio - это самый современный вариант работы с подобными вещами

кек лол

нет, asyncio - это самый современный вариант работы с подобными вещами

с выполнением множеств задач по таймерам, например?

с выполнением множеств задач по таймерам, например?

выполнение множества задач по таймерам - это cron. Но да, asyncio тоже так может

щас бы писать адовый бойлерплейт вместо ThreadPool.map()

Просто 2 пай скрипта будет?

ну, я бы взял фласк и я бы взял cron

щас бы писать адовый бойлерплейт вместо ThreadPool.map()

это какой? ты про asyncio.gather()?

бойлерплейт my ass

ну, я бы взял фласк и я бы взял cron

Ок, спасибо

выполнение множества задач по таймерам - это cron. Но да, asyncio тоже так может

но нафик мне asincio, если с нужной мне задачей справляется threading прекрасно в 2 строчки кода?

но нафик мне asincio, если с нужной мне задачей справляется threading прекрасно в 2 строчки кода?

потому что asyncio справится с ней же быстрее в большинстве случаев, если это i/o задача

и точно так же в пару строчек

потому что asyncio справится с ней же быстрее в большинстве случаев, если это i/o задача

но мне не надо быстрее, в принципе, в этом весь смысл

есть некоторые вещи, которые в современном мире имеет смысл писать НЕ на asyncio

но их не так много

но мне не надо быстрее, в принципе, в этом весь смысл

так и скажи - ниасилил и забил

асилил и забил

асилил и забил

= ниасилил

ойвсе

банальная задача - запустить сабпроцесс и одновременно писать и читать ему stdin/stdout

я посмотрю, как ты это сделаешь без asyncio

но у меня-то другая задача... зачем ты мне выдумываешь задачи под решение

но у меня-то другая задача... зачем ты мне выдумываешь задачи под решение

так какая у тебя?

Всем привет! Скажите пож, а почему вот такая строка может возвращать ошибку? plt.title(str(errors[i])) errors[i] возвращает текст Traceback (most recent call last): File "C:\Users\313457\PycharmProjects\Error report\GIT\Report.py", line 158, in <module> err_graph(top, data) File "C:\Users\313457\PycharmProjects\Error report\GIT\Report.py", line 76, in err_graph plt.title(str(errors[i])) KeyError: 'Mobile not verified' Process finished with exit code 1

Всем привет! Скажите пож, а почему вот такая строка может возвращать ошибку? plt.title(str(errors[i])) errors[i] возвращает текст Traceback (most recent call last): File "C:\Users\313457\PycharmProjects\Error report\GIT\Report.py", line 158, in <module> err_graph(top, data) File "C:\Users\313457\PycharmProjects\Error report\GIT\Report.py", line 76, in err_graph plt.title(str(errors[i])) KeyError: 'Mobile not verified' Process finished with exit code 1

не найден ключ 'Mobile not verified' в словаре errors

ERROR: S client not available

Ой, туплю, спасибо!

но у меня-то другая задача... зачем ты мне выдумываешь задачи под решение

ну расскажи задачу уже, чо ты

ну расскажи задачу уже, чо ты

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

в одном потоке затык в одном таске блокирует выполнение всех остальных... а так управлением (созданием и удалением) всех задач просто занимается основной поток в цикле

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

с задержками - это как? просто периодически в цикле?

с задержками - это как? просто периодически в цикле?

в цикле основного потока задачи создаются и уничтожаются....

а какая периодичность?

от нескольких секунд до нескольких минут

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

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

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

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

в питоне не особо есть, но я пытаюсь всегда из задачи исходить

чтобы инструмент подобрать

в общем случае GIL в трединге только замедлить программу даже по сравнению с одним потоком позволяет

там где threading не подходит, есть multiprocessing и asyncio.... Но питон чаще вообще однозадачный, и тут GIL важнее вот этой особенности работы потоков

в общем случае GIL в трединге только замедлить программу даже по сравнению с одним потоком позволяет

по сравнению с одним потоком вроде начиная с 3.2 уже нет.... не медленнее

ну, не настолько медленнее, по крайней мере, чтоб это имело решающее значение

до 3.2 вообще, конечно, катастрофа была

там где threading не подходит, есть multiprocessing и asyncio.... Но питон чаще вообще однозадачный, и тут GIL важнее вот этой особенности работы потоков

multiprocessing - адский костыль с диким оверхедом, он крайне плохо заменяет потоки

по сравнению с одним потоком вроде начиная с 3.2 уже нет.... не медленнее

ну это ты намекаешь, видимо, на то, что в 3.2 починили, что sleep таки отпускает гил :)

Если присмотреться, gil выполняет роль лупа в мультитрединге. Просто постоянно переключает потоки.

Только потоки ресурсов жрут больше

ну это ты намекаешь, видимо, на то, что в 3.2 починили, что sleep таки отпускает гил :)

да не, sleep и раньше гил отпускал.... проблема-то, когда два ядра процессора(два процессора) пытаются между собой поделить 2 потока, а GIL им не дает... и начиналась битва!

вот эту хрень и починили в 3.2

http://www.dabeaz.com/python/NewGIL.pdf

да не, sleep и раньше гил отпускал.... проблема-то, когда два ядра процессора(два процессора) пытаются между собой поделить 2 потока, а GIL им не дает... и начиналась битва!

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

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

Управление потоками на уровне ОС же осуществляется

Управление потоками на уровне ОС же осуществляется

https://en.wikipedia.org/wiki/Processor_affinity

я вот про это

по дефолту affinity как-раз не выставлен

но можно