poplib for multihomed machines

Donn Cave donn at u.washington.edu
Wed Jun 30 14:51:33 EDT 2004


In article <9418be08.0406300932.6bacb6f8 at posting.google.com>,
 elbertlev at hotmail.com (Elbert Lev) wrote:

> > If the practical issues can be resolved by factoring the
> > network connection out into a separate function, then that's
> > a practical solution, don't you think?
> 
> Fixing this particular piece of code is very simple. But let's talk
> about big system. If all classes in standard library are written like
> POP3 class (and most of them are) you will "tailor for your needs"
> most of them. Not subclass but copy and modify! So the standard
> library becomes a "reference material". The classes in standard
> library use other pieces of standard library (who does not?). If these
> pieces change you have to track the changes and incorporate into your
> code. (if you subclass in most cases subclased class takes care of
> modifications).
> 
> I'm not talking about a casual script, which runs on you PC and copies
> files from one directory to a backup storage. I'm talking about realy
> big system...
> 
> So the answer is NO. I don't think that copy and paste is the best
> solution. In other words if you are in OOP world do not use concrete
> classes.

I'm not sure I'm following this.  Is some part of your
message here a response to the paragraph you quoted from me?

I don't think anyone would argue that it's better if we can
accomplish what we want with a subclass, rather than copying
code out of the library, and I think the author of the POP3
class might agree that this is a deficiency that should be
corrected, especially if that can be done without breaking
current applications.  And we know how to do that, right?

I imagine the authors of other standard libraries would
also appreciate suggestions if they present similar problems.
They might also be interested in your ideas about OOP, but
there's nothing better than a good solution to real, practical
problem as a way to present those ideas.

   Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list