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

[boB Stepp]

On Thu, Jun 16, 2016 at 11:40 AM, Alan Gauld via Tutor <tutor at python.org> wrote:
> On 16/06/16 16:38, boB Stepp wrote:
>
>> class FTPFiles(FTP, object):
>>     """FTP files to Windows server location(s)."""
>
> OK, First comment. You describe this as an action(verb)
> rather than a noun. Classes should represent nouns
> (objects) not actions. FTP represents a protocol
> connection with which you can do things (one of
> which is put/get files) you class should be the same.
> (Remember inheritance m,eans you are imp0lementing
> an "is a" relationship. So FTPFiles is an FTP...or
> should be.)

I was struggling to come up with a good name here that would not cause
me any name collision issues with the contents of ftplib.FTP().  I
have for the moment changed the class name to "CustomFTP", which
bothers me for some reason that I cannot put my finger on.  However,
this looks to become a non-issue; see below.

>> 4)  As this class stuff is mostly treading new ground for me, am I
>> doing anything that I should not be doing or should do in a more
>> preferred way?  Keep in mind that I am just starting on this code
>> today.
>
> I'll leave someone with more ftplib experience to answer the other
> points but the question I'd ask is what are you planning to add to FTP?
> Creating a new class by inheritance implies that you are going to be
> extending (or specializing) its capabilities in some way. What are you
> planning to extend/specialize? For example are you going to limit it to
> manipulating files only? ie prevent listing directories say?

My first objective was just to play around with inheritance as a
learning opportunity.  Now that I have gotten it to work and have
somewhat a feel for the possibilities, I am actually going to abandon
it for this specific project.  I think I can use the FTP class
unmodified and just write appropriate helper functions to get the
specifics of what I want, passing my specific FTP instance object to
these functions.

> You need to know what you are changing to warrant using inheritance.
> Inheritance is a powerful tool but it carries lots of potential for
> problems too, especially if you plan on mixing your new class in with
> the old one (or sharing it with others who will) - you need to be
> careful to abide by the Liskov substitution principle (LSP).

I looked up LSP last night.  I can see how I can easily get burned
even on something seemingly simple.  One example, which I imagine is
often used, is of a square class inheriting from a rectangle class.
Squares have same sized sides; rectangles not necessarily so.  So any
size changing methods from the rectangle class inherited by the square
class can potentially wreak havoc on squares.  Am I getting the
essence of the potential issues I might encounter?

boB