Op 2004-12-13, Tim Peters schreef <[EMAIL PROTECTED]>: > [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.
By that argument any use of locks is bad practice because it can lead to deadlock. > 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. If a car model has cranky brakes, I think I can call that a failing even without having the ability to come up with a pratical design that doesn's has those limitations. I judge a language by what it can and cannot do, not by my ability to correct the things I perceive as failings. For all I know python may have taken some design decisions that might have seen perfectly logical but now prohibit a a practical design that doesn't have this limitation. I don't see why something like that would make this any less a failing then when a practical design was easy in the current implemenation. > 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. Importing a module in general also does some kind of initialisation. If starting a thread is a logical thing to do in this initialisation fase I see nothing wrong with it. > 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. Well I'll agree here. An import that has as a side effect that the import doesn't return is bad practice. > 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. Well in that case I don't have any problems with it. The perceived failing was because of only knowing part of it based on what I had read in this thread. > 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. Well then probably I have a bad taste. I have though of designs in which it seemed very natural to have a thread started as part of the initialisation in a module. Other limitations of python didn't make it workable but in priciple I saw nothing wrong with doing it. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
