issues with doctest and threads

Michele Simionato michele.simionato at
Wed Aug 10 14:32:56 CEST 2005

Tim Peters wrote:
> Because the program is buggy:  synchronizing threads isn't a "do it if
> you feel like it" thing, it's essential to correct threaded behavior.
> If you're going to show students bad thread practice, they're going to
> get mysteries a lot deeper and more damaging than this one <0.5 wink>.

Well, yes, but here I am using bad practices *on purpose*, trying
to figure out the most likely mistakes of my students. I want to show
what they should NOT do, and what happens if they do. I personally
don't have
that much practice with threads (for instance, I knew about .join() but
I forgot to use it) so it is also good for me if I do some mistake.
the course is not about threads, but I might cover them as an optional

> Properly synchronize the thread, to enforce what the code requires but
> cannot hope to obtain by blind luck.  All it takes is the
> thread.join() I suggested.  I don't understand why you're fighting
> that, because it's basic proper thread practice -- it's not like I
> suggested an obscure expert-level hack here.

I am not fighting .join() at all; but I want to know what I should
in case I do a mistake. This is pretty useful in case I had to debug a
threaded program written by my students.

> If a student doesn't
> know to join() a thread before they rely on that thread being done,
> their thread career will be an endless nightmare.

This is exactly the reason why I want to show them what happens if they
don't use it ;)

> All that said, this specific failure would _happen_ to go away too, if
> in doctest's, the final 'test.globs.clear()" were
> removed.  If you feel it's necessary to let threads spawned by a
> doctest run beyond the time doctest completes, you can arrange to
> invoke with clear_globs=False.

Perfect, this answers my question and gives me an useful tip about

Thanks a lot!

       Michele Simionato

More information about the Python-list mailing list