thread/queue bug

[Antoon Pardon]

Op 2004-12-14, Steve Holden schreef <steve at holdenweb.com>:
> Antoon Pardon wrote:
>
>> Op 2004-12-13, Tim Peters schreef <tim.peters at gmail.com>:
>> 
>>>[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