PySocks-ის ნაგულისხმევი ftplib-ს არ გადამისამართებს
თვალყური ადევნეთ socket-ებს, რომლებსაც ftplib რეალურად ქმნის, ნაცვლად იმისა, რომ ჩათვალოთ, თითქოს set_default_proxy ცვლის Python-ის მშობლიურ socket-ის იმპლემენტაციას.
socks.set_default_proxy() ინახავს ნაგულისხმევ მნიშვნელობებს მომავალი PySocks socksocket ობიექტებისთვის. ის არ ცვლის Python-ის მშობლიურ socket კლასს. შესაბამისად, ის ftplib-ს არ გადამისამართებს მხოლოდ იმიტომ, რომ გამოძახება FTP კავშირამდე ხდება.
თვალყური ადევნეთ კონსტრუქტორებს და არა ცვლადს, რომელიც პროქსის URL-ს ინახავს. ftplib ქმნის საკონტროლო კავშირს და დამატებით გადაცემის კავშირებს. პასიურ FTP-ში წარმატებული შესვლა მხოლოდ იმას ამტკიცებს, რომ საკონტროლო კავშირი მუშაობდა; ჩამონათვალისა და ფაილის გადაცემისთვის გამოყენებულ მონაცემთა socket-საც სჭირდება განკუთვნილი მარშრუტი.
რეცეპტი, რომელიც ცვლის socket.socket-ს ან ახვევს მოდულს, ასრულებს სხვა მოქმედებას PySocks-ის ნაგულისხმევი მნიშვნელობების დაყენების გარდა. მან შეიძლება გავლენა მოახდინოს სხვა ბიბლიოთეკებზე, რომლებიც იმ მოდულს იზიარებენ. ორიგინალის დროებითი აღდგენა შემდეგ ერთდროულ კავშირებს ცვლილებისგან არ აცილებს.
მორგებულ ftplib ქვეკლასს შეუძლია კავშირის ბილიკები დაფაროს, მაგრამ კოპირებული შიდა ნაწილები თან ატარებს იმ Python-ის გამოშვების დაშვებებს, საიდანაც მოვიდნენ, მათ შორის დროის ლიმიტის სენტინელებსა და პროტოკოლის დამუშავებას. სტანდარტული ბიბლიოთეკის განახლებები ასლს არ აახლებს.
აირჩიეთ მხარდაჭერილი კლიენტი ან მხარდაჭერილი ინტეგრაცია საჭირო პროქსისა და FTP რეჟიმისთვის. PycURL-ით პასიური FTP ჩამოტვირთვის მაგალითი ცალკე კლიენტის ბილიკს აჩვენებს. აპლიკაციის საკუთრებაში არსებული მორგებისთვის დაადგინეთ, რომელი კონსტრუქტორი ხსნის ყოველ საკონტროლო და მონაცემთა socket-ს, და შეინარჩუნეთ ის ზედა დონის ქცევა, რომელსაც ის ცვლის. სწორი პროქსის მნიშვნელობა მხოლოდ მაშინაა სასარგებლო, როცა ეს კონსტრუქტორები ნამდვილად იყენებენ მას.