Samle kvart resultat frå samtidige urllib3-proxyførespurnader

Å lage eit arbeidarbasseng gjev ikkje innringaren dei nedlasta sidene. Ta vare på og bruk verdiane som det innsende arbeidet returnerer:

from concurrent.futures import ThreadPoolExecutor
import urllib3

manager = urllib3.ProxyManager(
    'http://proxy.example:8080',
    maxsize=4,
    block=True,
)

def fetch(url):
    response = manager.request(
        'GET', url, timeout=urllib3.Timeout(connect=5, read=15),
    )
    return url, response.status, response.data

try:
    with ThreadPoolExecutor(max_workers=4) as workers:
        results = list(workers.map(fetch, urls))
finally:
    manager.clear()

Dette utdraget føreset ei avgrensa liste med URL-ar og vanlege svarstorleikar. For tillatne offentlege URL-kontrollar utan proxyautentisering kan ein kandidat frå HTTP-proxylista erstatta døme-HTTP-endepunktet til leiaren. Kvart resultat inneheld URL-en sin slik at innringaren kan knyta status og brødtekst til rett førespurnad. map returnerer resultat i inndataorden; eit unntak i ein arbeidar blir utløyst når det resultatet blir henta.

Den konfigurerte ProxyManager eig tilkoplingsbassenget for førespurnadene. Med standard førehandslasta svar-modus som blir brukt her, les urllib3 brødteksten og returnerer tilkoplingspunktet til bassenget sitt. Ein strøymande versjon ville trenga eksplisitt forbruk og frigjering av tilkoplingspunktet.

maxsize styrer vanlegvis haldne gjenbrukbare tilkoplingspunkt, ikkje ei hard grense for kvar opna socket. block=True endrar den relevante bassengåtferda slik at innringarar ventar på eit ledig tilkoplingspunkt i staden for å opna fleire utover grensa til det bassenget.

Talet på arbeidarar avgrensar samtidige kall i dette dømet. Med mange destinasjonar har òg bassengoppsettet og ruta som blir brukt for HTTPS-tunnelar noko å seia; ei innstilling per basseng bør ikkje skildrast som ein global socketkvote for kvar vert.