nntplib, huge xover object

carroll at tjc.com carroll at tjc.com
Sat Apr 5 20:57:07 CEST 2003

On Sat, 05 Apr 2003 18:11:50 GMT, Robin Munn <rmunn at pobox.com> wrote:

>First, from what you've written above, it sounds like you're doing
>type-checking to determine whether the parameter is a string or a file.

Actually, I'm just accepting the additional parameter, representing a
string (interpreted as a filename) or an open file object, and passing
that along to an internal method longcmd(), that accepts either, which
in turn passes it along to the internal getlongresp().  getlongresp()
is the part that acts differently depending on the presence of the

getlongresp() does do type checking.  In the version I have, it's

  if isinstance(file, types.StringType):

and the latest CVS is:

  if isinstance(file, str):

But that's exiting code, nowhere near anyplace I'm touching.  My
inclination is to leave it alone.

Up until now, the aspect of writing to a file instead of the returned
list is only used for the body() method; I'm just extending it to
xover() and probably a few others.

>You may not be doing type-checking, in which case this advice doesn't
>apply to you, but type-checking is the wrong way to go about that. Do
>interface checking instead, e.g.:
>    # Is it a file-like object?
>    try:
>        output_file.write
>        print "output_file is a file-like object"

Just curious; why is this preferred?  Serious question; I'm relatively
new to Python, and still learning a lot.

I'm thinking it might be two different philosophies.  The one in the
present nntplib will try to invoke write() in whatever object was
passed to it, and if the caller invoked it with the wrong object type,
he'll get an error.  The one above seems to change the spec to support
any object that has a method named "write."

>Second, do *not* use the name "file" as your parameter name; you will
>shadow the file builtin.

That's already in nntplib.  I'm just making xover() consistent with

>Third, I'm not sure I like the functionality of passing a string
>filename. It sounds convenient, but all it really does is *add*
>ambiguity to your function which could be avoided.

I'd probably do it that way if I were doing it from scratch, but I
don't want to reinvent the wheel, and I think maintaining consistency
with the body() call is a Good Thing.

>Other than that, nice job.

Thanks, and thanks for the feedback.

By the way, I should really point out that my changes are relatively
trivial.  It's Travers Naran, who modified nntplib to support a file
parameter on body(), and did it in a particularly flexible way to make
it easy to extend to the other user-called methods, that deserves the
bulk of the credit.

More information about the Python-list mailing list