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
them
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.
Luckily
the course is not about threads, but I might cover them as an optional
topic.
> 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
expect
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 DocTestRunner.run(), 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 DocTestRunner.run() with clear_globs=False.
Perfect, this answers my question and gives me an useful tip about
doctest
globals.
Thanks a lot!
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
