Hindi binabago ng default ng PySocks ang ruta ng ftplib
Subaybayan ang mga socket na aktwal na ginagawa ng ftplib sa halip na ipagpalagay na binabago ng set_default_proxy ang native na implementasyon ng socket sa Python.
socks.set_default_proxy() ay nagtatabi ng mga default para sa mga susunod na object na PySocks socksocket. Hindi nito pinapalitan ang native na socket class ng Python. Kaya hindi nito binabago ang ruta ng ftplib dahil lang sa nangyari ang tawag bago ang koneksyon sa FTP.
Subaybayan ang mga constructor, hindi ang variable na may hawak ng URL ng proxy. Gumagawa ang ftplib ng isang control connection at karagdagang mga transfer connection. Sa passive FTP, pinatutunayan lamang ng matagumpay na login na gumana ang control connection; ang data socket na ginagamit para sa listahan o paglilipat ng file ay kailangan din ng nilalayong ruta.
Ang recipe na pumapalit sa socket.socket o bumabalot sa isang module ay gumagawa ng ibang bagay bukod sa pagtatakda ng mga default ng PySocks. Maaari nitong maapektuhan ang ibang library na gumagamit ng parehong module. Ang pagbalik sa orihinal pagkatapos ay hindi naghihiwalay sa magkasabay na koneksyon mula sa pagbabagong iyon.
Maaaring saklawin ng custom na subclass ng ftplib ang mga landas ng koneksyon, ngunit ang nakopyang panloob ay nagdadala ng mga palagay ng bersyon ng Python na pinagmulan nito, kasama ang timeout sentinel at paghawak ng protocol. Hindi ina-update ng mga update ng standard library ang kopya.
Pumili ng pinapanatiliang client o sinusuportahang integration para sa kinakailangang proxy at FTP mode. Ang halimbawa ng passive FTP download gamit ang PycURL ay nagpapakita ng hiwalay na landas ng client. Para sa pagpapasadya na pag-aari ng application, tukuyin kung aling constructor ang nagbubukas ng bawat control at data socket at panatilihin ang upstream na pag-uugali na pinapalitan nito. Ang tamang halaga ng proxy ay kapaki-pakinabang lamang kapag aktwal na ginagamit ito ng mga constructor na iyon.