En PySocks-standard dirigerar inte om ftplib
Följ de sockets som ftplib faktiskt skapar i stället för att anta att set_default_proxy byter ut Pythons inbyggda socket-implementering.
socks.set_default_proxy() sparar standardvärden för framtida PySocks-socksocket-objekt. Det ersätter inte Pythons inbyggda socketklass. Därför dirigerar det inte om ftplib bara för att anropet sker före en FTP-anslutning.
Följ konstruktorerna, inte variabeln som håller proxy-URL:en. ftplib skapar en styranslutning och ytterligare överföringsanslutningar. Med passiv FTP bevisar en lyckad inloggning bara att styranslutningen fungerade; även datasocketen som används för en listning eller filöverföring behöver den avsedda vägen.
Ett recept som ersätter socket.socket eller lindar in en modul gör något annat än att sätta PySocks-standardvärden. Det kan påverka andra bibliotek som delar samma modul. Att återställa originalet efteråt gör inte samtidiga anslutningar isolerade från ändringen.
En egen ftplib-underklass kan täcka anslutningsvägarna, men kopierade interna delar bär med sig antagandena från den Python-version de kom ifrån, inklusive timeout-sentinelar och protokollhantering. Uppdateringar av standardbiblioteket uppdaterar inte kopian.
Välj en underhållen klient eller en stödd integration för den proxy och det FTP-läge som krävs. Ett exempel på passiv FTP-nedladdning med PycURL visar en separat klientväg. För anpassning som applikationen äger, ta reda på vilken konstruktor som öppnar varje styr- och datasocket och behåll beteendet den ersätter. Ett korrekt proxyvärde är bara användbart när konstruktorerna faktiskt använder det.