tim.peters at gmail.com
Mon Dec 13 16:17:52 CET 2004
> I don't see why starting a thread as a side effect of importing is
> bad thread practice. Sure python doesn't cater for it, but IMO
> that seems to be python failing.
Obviously, it's bad practice in Python because it can lead to
deadlocks in Python. It's nearly tautological. Import is an
executable statement in Python, not, e.g., as in many other languages,
a declaration directed at the system linker. With that power comes
opportunities to shoot yourself, although they're generally easy to
avoid. Come up with a practical design that doesn't have this
limitation, and then perhaps your characterization of the current
design as "a failing" would be both credible and constructive.
Apart from that, ya, I do think it would *uisually* be poor practice
to start a thread as a side effect of importing anyway. It's too
mysterious, and IME has caused trouble even when it didn't lead to
deadlocks. The fundamental purpose of import in Python is to add
useful names to the importer's namespace, and users of a module
generally think of it as doing no more than that.
Note that the OP's example had a module that, upon the first attempt
to import it, ran an infinite loop (even if it hadn't deadlocked), and
it's clearly severe abuse of import's purpose.to write a module M such
that "import M" *never* returns. Indeed, that's the other half of how
deadlock occurs: not only that the imported module spawn a thread as
a side effect of importing, but also that the imported module refuse
to allow the import to complete.
The current design actually supports spawning all the threads you like
as a side effect of importing, provided you ensure also that the
import ompletes. The easiest way to avoid trouble remains not to
spawn threads as a side effect of importing to begin with, although a
programmer determined to demonstrate their bad taste <wink> can easily
enough make it work.
More information about the Python-list