Un valore predefinito di PySocks non reindirizza ftplib
Seguite i socket che ftplib crea davvero invece di supporre che set_default_proxy modifichi l'implementazione nativa di socket di Python.
socks.set_default_proxy() memorizza valori predefiniti per i futuri oggetti PySocks socksocket. Non sostituisce la classe socket nativa di Python. Di conseguenza, non reindirizza ftplib solo perché la chiamata avviene prima di una connessione FTP.
Seguite i costruttori, non la variabile che contiene l'URL del proxy. ftplib crea una connessione di controllo e connessioni di trasferimento aggiuntive. In FTP passivo, un accesso riuscito dimostra solo che la connessione di controllo ha funzionato; anche il socket dati usato per un elenco o un trasferimento di file necessita del percorso previsto.
Una ricetta che sostituisce socket.socket o avvolge un modulo compie un'azione diversa dall'impostare i valori predefiniti di PySocks. Può influire su altre librerie che condividono quel modulo. Ripristinare temporaneamente l'originale in seguito non isola le connessioni simultanee dalla modifica.
Una sottoclasse personalizzata di ftplib può coprire i percorsi di connessione, ma le interiora copiate portano con sé le assunzioni della versione di Python da cui provengono, comprese le sentinelle di timeout e la gestione del protocollo. Gli aggiornamenti della libreria standard non aggiornano la copia.
Scegliete un client mantenuto o un'integrazione supportata per il proxy e la modalità FTP richiesti. Un esempio di download FTP passivo con PycURL illustra un percorso client separato. Per una personalizzazione di proprietà dell'applicazione, individuate quale costruttore apre ogni socket di controllo e dati e preservate il comportamento a monte che sostituisce. Un valore proxy corretto è utile solo quando quei costruttori lo consumano davvero.