Запросы Python: не дожидаться завершения запроса
В Bash можно выполнить команду в фоновом режиме, добавив & . Как я могу сделать это в Python?
while True: data = raw_input('Enter something: ') requests.post(url, data=data) # Don't wait for it to finish. print('Sending POST request...') # This should appear immediately.
4 Solutions collect form web for “Запросы Python: не дожидаться завершения запроса”
Я использую multiprocessing.dummy.Pool . Я создаю одиночный пул потоков на уровне модуля, а затем использую pool.apply_async(requests.get, [params]) для запуска задачи.
Эта команда дает мне будущее, которое я могу добавить в список с другими фьючерсами неограниченно, пока не захочу собрать все или некоторые результаты.
multiprocessing.dummy.Pool – против всей логики и причины – пул THREAD, а не пул процессов.
Пример (работает как на Python 2, так и на 3, если установлены запросы):
from multiprocessing.dummy import Pool import requests pool = Pool(10) # Creates a pool with ten threads; more threads = more concurrency. # "pool" is a module attribute; you can be sure there will only # be one of them in your application # as modules are cached after initialization. if __name__ == '__main__': futures = [] for x in range(10): futures.append(pool.apply_async(requests.get, ['http://example.com/'])) # futures is now a list of 10 futures. for future in futures: print(future.get()) # For each future, wait until the request is # finished and then print the response object.
Запросы будут выполняться одновременно, поэтому выполнение всех десяти этих запросов должно занимать не больше самого длинного. Эта стратегия будет использовать только одно ядро ЦП, но это не должно быть проблемой, потому что почти все время будет потрачено на ожидание ввода-вывода.
Если вы можете написать код, который будет выполняться отдельно в отдельной программе python, это возможное решение, основанное на подпроцессе.
В противном случае вам может оказаться полезным этот вопрос и связанный с ним ответ: фокус в том, чтобы использовать библиотеку потоков для запуска отдельного потока, который будет выполнять разделенную задачу.
Оговоркой с обоими подходами может быть количество элементов (то есть количество потоков), которыми вы должны управлять. Если item s в parent слишком много, вы можете приостановить каждую партию элементов до тех пор, пока по крайней мере некоторые потоки не закончатся, но я считаю, что такое управление является нетривиальным.
Для более сложного подхода вы можете использовать подход, основанный на актерах, я сам не использовал эту библиотеку, но я думаю, что это может помочь в этом случае.
Согласно документу , вы должны перейти в другую библиотеку:
Блокировка или блокировка?
При использовании адаптера транспорта по умолчанию в запросах не предусмотрен какой-либо неблокирующий IO. Свойство Response.content будет заблокировано до тех пор, пока не будет загружен весь ответ. Если вам требуется больше детализации, потоковые функции библиотеки (см. «Запросы потоковой передачи») позволяют вам получать меньшее количество ответов за раз. Однако эти вызовы будут по-прежнему блокироваться.
Если вас беспокоит использование блокировки ввода-вывода, есть много проектов, которые объединяют запросы с одной из систем асинхронности Python.
Два отличных примера – это графики и запросы-фьючерсы .
Вот хакерский способ сделать это:
try: requests.get("http://127.0.0.1:8000/test/",timeout=0.0000000001) except requests.exceptions.ReadTimeout: pass-try: requests.get("http://127.0.0.1:8000/test/",timeout=0.0000000001) except requests.exceptions.ReadTimeout: pass