Message197052
| Author |
pitrou |
| Recipients |
Tamas.K, csernazs, grahamd, jcea, ncoghlan, neologix, pitrou, python-dev, tim.peters |
| Date |
2013年09月06日.06:31:47 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1378449102.2487.4.camel@fsol> |
| In-reply-to |
<1378426766.78.0.328967780995.issue18808@psf.upfronthosting.co.za> |
| Content |
Le vendredi 06 septembre 2013 à 00:19 +0000, Tim Peters a écrit :
> Tim Peters added the comment:
>
> So you're not concerned about a now-private API (which used to be
> advertised), but are concerned about a user mucking with a new private
> lock in an exceedingly unlikely (in the absence of malice) way. That
> clarifies things ;-)
:-)
The only reason I'm concerned about the user mucking with the private
lock is that it's a new opportunity that's opened. But, yeah, I could
remove the weakref and only keep the lock. The code would only be ~10
lines shorter, though. What do other people think?
> in its end-of-life code. Essentially rolling their own clumsy variant
> of a Semaphore.
I guess they spell it like:
import clumsy_threading as threading
> I've seen code like that "in the wild".
Well, I've sure seen my share of sleep() calls as a synchronization
measure too (and removed a number of them)... :-)
That's one of the reasons I added the timeout arguments, actually. |
|