Op 2004-12-14, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> 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. >> > Not at all. You mentioned locks, not Tim.
That is beside the point. The argument was that starting a thread as a side effect of importing is bad practice because it can lead to deadlock. This suggest that a general condition for something to be bad practice is if that something can lead to deadlock. Locks are in that case. >>>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. >> > But in fact your situation is more closely analogous to a customer who's > bought a car that can be stopped by pressing on the brake pedal now > complaining that sideways pressure on the brake pedal doesn;t affect the > car's motion. You will have to explain how you come by that analogy. >> 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. >> > All that Tim was suggesting is that it's MORE SENSIBLE to start a thread > as the result of a specific call to programmed functionality rather than > as the side effect of an import. The reason for this is due to the > semantics of the import statement. If you perceive that as a failing > then you'd be better rewarded by an attempt to modify your perceptions. > I've always found "don't argue with Tim about Python" to be a useful > rule of thumb. He's wrong much less often than I am. I suspect he's also > wrong much less often than you ;-) With all respect I find that lousy advise. I don't mind that it will turn out I'll be wrong most of the time. But I'll probably will have gained a better understanding by the responses to my argument than by merely accepting the word of Tim. [ ... ] >>>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. >> > But that's precisely the risk you run when starting up threads! Now you are confusing me. Is it a problem of an import that doesn't return of is it a case of a race condition where the import has to return in a timely fashion? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list