(solved) smtplib, capturing output from set_debuglevel ??

[Josiah Carlson]

> Ahh, that would explain why my examples replaced
> smtplib.stderr while others replaced sys.stdout.  I'm
> working out of a CVS build.

If I were in a situation where I cared about output, I'd be using the
version from CVS.  In fact, if I were to make one suggestion to Tim, it
would be to switch from his custom version of smtplib to the version in
CVS, then do anything to smtplib.stderr that he wants.  If/when he
eventually upgrades to 2.4, he then doesn't even need to worry about his
copy of CVS smtplib, he gets that by default.


> In a cursory look of your code I though you were implementing
> a sort of thread local storage.  Looking at it again I don't
> see how
> 
>          thread = threading.currentThread().getName()
>          try:
>              self.lock.acquire()
>              if thread in self.ios:
>                  self.ios[thread].write(data)
>              else:
>                  t = self.ios[thread] = StringIO()
>                  t.write(data)
>          finally:
>              self.lock.release()
> 
> isn't using thread local storage in
>     self.ios[threading.currentThread().getName()]

It is a kind of per-thread storage, but you can get at the data any time
from any thread (via multi_thread_output.get_ready() ). From what I
understand of generic Python thread local storage gained from the
docstring in CVS for the Python implementation here:
   <http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/_threading_local.py?rev=1.3&view=markup>

...other threads cannot access Python standard thread local storage.


 - Josiah