[Antoon Pardon] > 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. -- http://mail.python.org/mailman/listinfo/python-list