از تغییرات سراسری opener در urllib در بررسی‌کننده‌های پروکسی پرهیز کنید

from urllib.request import ProxyHandler, build_opener

def make_proxy_opener(proxy_uri):
    return build_opener(ProxyHandler({
        "http": proxy_uri,
        "https": proxy_uri,
    }))

opener = make_proxy_opener("http://proxy.example.net:8080")
# Use opener.open(destination, timeout=10) for this route.

وقتی مسیری به بررسی تعلق دارد، متد open خود همین opener را فراخوانی کنید. نقطه پایانی HTTP در مثال ممکن است از سرویس شما یا از فهرست پروکسی HTTP برای بررسی‌های عمومی بیاید. این قطعه مالکیت را نشان می‌دهد؛ سیاست کامل احراز هویت یا سلامت را تعریف نمی‌کند. هر handler مخصوص حساب را به همان کلاینت موردنظر متصل نگه دارید.

urllib.request.install_opener() پیش‌فرض سراسری فرایند را که فراخوانی‌های بعدی urlopen() در سطح ماژول استفاده می‌کنند تغییر می‌دهد. بنابراین بررسی‌کننده‌ای که پروکسی‌ها را می‌پیماید می‌تواند درخواست‌های نامرتبط را با آخرین نقطه پایانی خود رها کند. نصب موقت و بازگردانی در پاک‌سازی هنوز به درخواست‌های هم‌زمان اجازه می‌دهد در طول تغییر مشترک اجرا شوند.

socket.setdefaulttimeout() نیز به همین ترتیب پیش‌فرض‌های سوکت‌هایی را که بعداً ساخته می‌شوند تغییر می‌دهد. وقتی فقط بررسی باید آن را دریافت کند، از مهلت در سطح عملیات استفاده کنید.

پاسخ‌های بررسی را ببندید و نتایج آن را مشخص نگه دارید: پاسخ خطای HTTP به‌طور خودکار یک شنونده پروکسی مرده نیست. اگر بررسی همگام urllib در سرویسی ناهمگام استفاده می‌شود، کار مسدودکننده را به worker مناسب منتقل کنید؛ این تصمیم اجرایی تغییر سراسری opener را جدا نمی‌کند.

یک بررسی باید مشاهده خود را بازگرداند بدون اینکه سیاست شبکه دیگری را پشت سر بگذارد. شیء کلاینت خودش و عملیات محدود، این مرز را صریح می‌کنند.