See please attached ZIP archive which contains the two simple example
source codes.

If you execute bb.py, let it running for a while and then press Ctrl+C
then the Python will terminate safely and you will get the following
output on your console:

E:\KkWebrman\Instalace\Tmp>bb.py
init
parsing time...
...done
started
parsing time...
...done
parsing time...
...done
finishing
done

E:\KkWebrman\Instalace\Tmp>

However, if you execute aa.py then it will not terminate by Ctrl+C and
you will get the following output on your console:

E:\KkWebrman\Instalace\Tmp>aa.py
init
parsing time...
started
finishing

The aa.py simply imports bb.

My OS is: MS Windows 2000.

My Python version is: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC
v.1310 32 bit (Intel)] on win32

Do you realise that the code at the bottom of bb.py is executed when you
import it from aa.py? In other words, when you run aa.py, the whole of
your significant code is running within an import statement. I don't
know if it's the cause of the problem (although I remember past
strictures on the messiness of threads and imports) but I doubt if it's
a fantastic design choice.

The reason for it is pragmatic: The whole of my application is published
as .pyc files. Except of the only one which must stay .py - that one
which has to be executable (+x) on Linux and thus it starts with the line:
# !/usr/bin/python
and then it should only contain:
import <something>
and <something> is .pyc.

So I did a simple change into my application. I start it via a very
brief script whic only contains:
# !/usr/bin/python
import <something>

Wow! It stopped working at all!

After 4 hours of isolating of the problem I developped an elementary
code which demonstrates my problem (attached at the bug report).

I expect that the import statement does not return the control until the
code being executed by it finishes, does'n it?

One more hint: There is the coincidence of three facts:
1. It uses the thread (if I remove the thread then it works fine).
2. It is "double imported" (if I remove the outer import then it works
fine).
3. There is the strptime() function being used (if I remove this
function then it works fine).

The deadlock happens because strptime has an import inside it, and
recursive imports are not allowed in different threads.

As a general rule and good coding style, don't run your code when the
module is imported, but put it in a function like "main" in the second
file,import it and call it from the first one. This will solve your problem.

Note that this happens to you with strptime, but could happen with a
lot, *a lot*, of functions that do this internal import of something
else. So, you'll never be sure.

You can follow the python-dev thread titled "Deadlock by a second import
in a thread" for more info.

In the mena time, by intuition, I have resolved my troube exactly the
way you recommend.

Thanks to you, currently I also know what is he core of the problem.

So the issue can be closed...