[Tutor] Py 2.4.4: Inheriting from ftplib.FTP()

Steven D'Aprano steve at pearwood.info
Fri Jun 17 11:14:23 EDT 2016


On Thu, Jun 16, 2016 at 10:38:13AM -0500, boB Stepp wrote:

> I am extremely gradually trying to dip my big toe into the waters of
> writing classes.

[...]
> What I learned today:
> 
> 1)  FTP from ftplib appears to be an old-style class.
> 
> 2)  I can't just use "class FTPFiles(FTP)" or I will be using old-style classes.
> 
> 3)  I need to use "class FTPFiles(FTP, object)" to use new-style
> classes and "object" must come AFTER "FTP".
> 
> 4)  I have to use "super(FTPFiles, self).__init__(host, user, passwd)"
> or I cannot successfully inherit from the FTP() class.  Also, "self"
> apparently must come AFTER "FTPFiles" in the super expression.
> 
> Questions:
> 
> 1)  Are there any more common "gotchas" that might be coming my way in
> trying to use a new-style class inheriting from an old-style class in
> ancient Py 2.4.4?

That's a very interesting question. I *think* the answer is "No", but I 
wouldn't put money on it.


> 2)  I don't have much knowledge about FTP processes.  This is being
> used on a secure intranet environment.  And I am using the ftplib for
> the first time.  In its docs it mentioned that the quit() method is
> the "polite" way to close the connection, but that an exception may be
> raised if the responds with an error to the "QUIT" command the method
> sends.  If this happens, will the connection close? 

According to the source code, yes.


> Or should I do something like:
> 
> try:
>     ftp.quit()
> except:
>     ftp.close()
> 
> ?  It seems here (If I should use the "try" block.) that a bare
> "except" is appropriate as I would think I would want to close the
> connection regardless of the type of error the "QUIT" command
> generates.

Bare except is nearly never appropriate. Consider:

try:
    fpt.quit()
except:
    ftp.close()


> 3)  The point of the print_welcome_msg() method is to be sure that I
> have actually successfully connected to the FTP server.  Is there a
> better way to check for connection success?

If the connect method doesn't raise an exception, it connected 
successfully. 




-- 
Steve


More information about the Tutor mailing list