PySocks ਦਾ ਡਿਫਾਲਟ ftplib ਦਾ ਰਾਹ ਨਹੀਂ ਬਦਲਦਾ
ਇਹ ਮੰਨਣ ਦੀ ਥਾਂ ਕਿ set_default_proxy Python ਦੀ ਮੂਲ socket ਕਾਰਜਸ਼ੀਲਤਾ ਬਦਲਦਾ ਹੈ, ਉਹ sockets ਟਰੈਕ ਕਰੋ ਜੋ ftplib ਅਸਲ ਵਿੱਚ ਬਣਾਉਂਦਾ ਹੈ।
socks.set_default_proxy() ਭਵਿੱਖ ਦੇ PySocks socksocket ਆਬਜੈਕਟਾਂ ਲਈ ਡਿਫਾਲਟ ਮੁੱਲ ਸੰਭਾਲਦਾ ਹੈ। ਇਹ Python ਦੀ ਮੂਲ socket ਕਲਾਸ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ। ਇਸ ਲਈ ਇਹ ਸਿਰਫ਼ ਇਸ ਕਰਕੇ ftplib ਦਾ ਰਾਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਕਾਲ FTP ਕਨੈਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ।
ਪ੍ਰੌਕਸੀ URL ਰੱਖਣ ਵਾਲੇ ਵੇਰੀਏਬਲ ਦੀ ਨਹੀਂ, ਕੰਸਟ੍ਰਕਟਰਾਂ ਦੀ ਪੈੜ ਲਓ। ftplib ਇੱਕ ਕੰਟਰੋਲ ਕਨੈਕਸ਼ਨ ਅਤੇ ਵਾਧੂ ਟਰਾਂਸਫਰ ਕਨੈਕਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ। passive FTP ਵਿੱਚ ਸਫਲ ਲੌਗਇਨ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕੰਟਰੋਲ ਕਨੈਕਸ਼ਨ ਕੰਮ ਕਰਦਾ ਸੀ; ਸੂਚੀ ਜਾਂ ਫਾਈਲ ਟਰਾਂਸਫਰ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ data socket ਵੀ ਲੋੜੀਂਦੇ ਰਾਹ ਰਾਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
socket.socket ਦੀ ਥਾਂ ਲੈਣ ਵਾਲੀ ਜਾਂ ਮੌਡਿਊਲ ਨੂੰ ਲਪੇਟਣ ਵਾਲੀ ਵਿਧੀ PySocks ਡਿਫਾਲਟ ਸੈੱਟ ਕਰਨ ਤੋਂ ਵੱਖਰੀ ਕਾਰਵਾਈ ਕਰਦੀ ਹੈ। ਇਹ ਉਹੀ ਮੌਡਿਊਲ ਵਰਤਣ ਵਾਲੀਆਂ ਹੋਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਅਸਲ ਨੂੰ ਬਹਾਲ ਕਰਨ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਚੱਲ ਰਹੇ ਕਨੈਕਸ਼ਨ ਉਸ ਬਦਲਾਅ ਤੋਂ ਅਲੱਗ ਨਹੀਂ ਹੁੰਦੇ।
ਇੱਕ ਕਸਟਮ ftplib ਉਪ-ਕਲਾਸ ਕਨੈਕਸ਼ਨ ਰਾਹਾਂ ਨੂੰ ਕਵਰ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਨਕਲ ਕੀਤੇ ਅੰਦਰੂਨੀ ਹਿੱਸੇ ਉਸ Python ਵਰਜਨ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ ਜਿੱਥੋਂ ਉਹ ਆਏ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ timeout sentinel ਅਤੇ protocol ਸੰਭਾਲ ਸ਼ਾਮਲ ਹੈ। ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਅਪਡੇਟ ਨਕਲ ਨੂੰ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦੇ।
ਲੋੜੀਂਦੇ ਪ੍ਰੌਕਸੀ ਅਤੇ FTP ਮੋਡ ਲਈ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਕਲਾਇੰਟ ਜਾਂ ਸਮਰਥਿਤ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਚੁਣੋ। PycURL ਨਾਲ passive FTP ਡਾਊਨਲੋਡ ਦੀ ਉਦਾਹਰਨ ਇੱਕ ਵੱਖਰਾ ਕਲਾਇੰਟ ਰਾਹ ਦਿਖਾਉਂਦੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਮਲਕੀਅਤ ਵਾਲੇ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਲਈ ਪਛਾਣੋ ਕਿ ਕਿਹੜਾ ਕੰਸਟ੍ਰਕਟਰ ਹਰ ਕੰਟਰੋਲ ਅਤੇ data socket ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਉਹ upstream ਵਿਵਹਾਰ ਬਚਾਓ ਜਿਸ ਦੀ ਇਹ ਥਾਂ ਲੈਂਦਾ ਹੈ। ਸਹੀ ਪ੍ਰੌਕਸੀ ਮੁੱਲ ਤਦ ਹੀ ਕੰਮ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਉਹ ਕੰਸਟ੍ਰਕਟਰ ਇਸਨੂੰ ਅਸਲ ਵਿੱਚ ਵਰਤਦੇ ਹਨ।