(solved) smtplib, capturing output from set_debuglevel ??

[Tim Williams]

----- Original Message ----- 
From: "Josiah Carlson" <jcarlson at uci.edu>
To: "Andrew Dalke" <adalke at mindspring.com>; <python-list at python.org>
>
> After perusing it (smtplib) for a bit, I notice how often the debug
> notices are peppered through.  Thankfully for the most recent CVS, they
> include 'print >>stderr, <stuff>' rather than the previous 'print
> <stuff>'.  At least it allows doing smtplib.stderr = <anything>, without
> affecting other modules that rely on a reasonable stderr.
>
> Subclassing smtplib (as I originally suggested) doesn't look like a
> viable option.

Once again,  thanks for everyone's comments :-)

The version of smtplib I have (python 2.3.4) has no redirection, just the
print <stuff> commands.   When investigating subclassing I could see how to
add a few funcitons,  but couldn't work out if there was a way to replace
the print/debug stuff without re-creating the functions they existed in.   I
came to the conclusion that it was non-trivial.

For my purposes,  adding a few lines it seemed the best option to give a
quick and 100% match to my requirements.

> > What the OP wants is handy for things like email programs
> > that want to give feedback to the user about what's going on.
> > It captures some steps that can't otherwise be done via
> > subclassing.
>
> Having written something similar, I have noticed that just the return
> codes and exceptions returned by smtplib calls to be sufficient for
> nearly everything.  I don't think I've ever set the debug level on the
> object.

I prototyped using smtplib.SMTP  to do "all" the work and also using
smtplib.SMTP  to create the connection and then control the conversation
myself.   The latter required what now appears to be an almost complete
duplication of the logic within the SMTP class - and writing that was
non-trivial for me at the time.  I decided to go with the simpler and more
reliable first option .   Logging is only recent requirement

> The OP also likes being able to add new debug messages,
> which can't be done through subclassing.  Perhaps through
> AOP?  :)

This was an added benefit that I stumbled on after changing smtplib,
though it does make logging the whole process easier.   I can pass comments
into the debug stream and the logger handles it all at the end of the
connection.

FYI,   this is how the server logs used to look,

[msg id], OutBound Server: 64.233.171.27
[msg id], Sending from:<python-list-bounces+*no-spam*=xxxxx.xxx at python.org>,
to:['<*no-spam*@gmail.com>']
[msg id], Sat, 09 Oct 2004 13:02:26 -0000 success:['<*no-spam*@gmail.com>'],
failed:[] size:4888

and this is how server logs look now  (I added a time-stamp to the debug
function, and removed the message data from debug and put it into  s.data()
so it can be used but only if needed   ),   The only change to the server
program itself  is to call s.debug() after s.quit() and then pass the
returned list to the logger.

[msg id], OutBound Server: 64.233.171.27
[msg id], Sending from:<python-list-bounces+*no-spam*=xxxxx.xxx at python.org>,
to:['<*no-spam*@gmail.com>']
[msg id], (13:02:25)  Connecting to 64.233.171.27 on port 25
[msg id], (13:02:26) 220 mx.gmail.com ESMTP 64si281751rna
[msg id], (13:02:26) ehlo My.Server
[msg id], (13:02:26) 250-mx.gmail.com at your service
[msg id], (13:02:26) 250-SIZE 20971520
[msg id], (13:02:26) 250 8BITMIME
[msg id], (13:02:26) mail
FROM:<python-list-bounces+*no-spam*=xxxxx.xxx at python.org> size=4888
[msg id], (13:02:26) 250 OK
[msg id], (13:02:26) rcpt TO:<*no-spam*@gmail.com>
[msg id], (13:02:26) 250 OK
[msg id], (13:02:26) data
[msg id], (13:02:26) 354 Go ahead
[msg id], (13:02:26) 250 OK 1097326875
[msg id], (13:02:26) quit
[msg id], (13:02:26) 221 mx.gmail.com closing connection
[msg id], Sat, 09 Oct 2004 13:02:26 -0000 success:['<*no-spam*@gmail.com>'],
failed:[] size:4888