Jou foar in applikaasje dy't Tweepy 4.14 syn API-klasse brûkt de proxy oan dy klient:

api = tweepy.API(
    auth,
    proxy="http://proxy.example:8080",
    timeout=20,
)

It fragmint giet derfan út dat Tweepy laden is en dat auth de besteande autentikaasje-ôfhanneler fan 'e applikaasje is. Proxy-routing ferfangt it akkount fan 'e provider of syn API-rjochten net. Wêr't iepenbiere tuskenpersoanen tastien binne, biedt de HTTP-proksylist kandidaten foar dizze HTTP-rûte sûnder proxy-akkount.

De dokumintearre API-klasse is Tweepy syn v1.1-ynterface. It proxy-argumint dêrfan leveret de HTTP-tuskenpersoan dy't foar oanfragen brûkt wurdt. In histoarysk resept dat urllib syn globale iepener ferfangt, konfigurearret gjin moderne klient waans wiere ferfier in Requests-sesje is.

Hâld de konfigurearre eksimplaar dêr't de operaasjes dien wurde. Dit objekt oanmeitsje en dan earne oars in oare API-eksimplaar oproppe lit de bedoelde rûte op it net-brûkte objekt.

Tweepy syn v2-klient is in aparte klasse mei in oare konstruktor. Pas de proxy-ynbou oan op dat ynterface ynstee fan oan te nimmen dat elk Tweepy-objekt de arguminten fan 'e API-klasse akseptearret. It eksplisite argumint hjirboppe is nuttich om de byhearrende klientgeneraasje te ûnderhâlden sûnder proxy-gedrach foar net-relatearre Python-bibleteken te feroarjen.

Relatearre artikelen